#archive-library-discussion

1 messages · Page 24 of 1

dawn merlin
#

calling the same method over and over again doesn't make sense

unique axle
#

and even in instances where that's not the case it's preferred due to how people use builders - adding single fields based on conditionals
bringing up "popularity" of method use is not something i'd deem considerable in the discussion of keeping singular or plural at all

dawn merlin
#

In addition addField will always have an advantage in terms of usage since you'll most likely have to call it multiple times as to opposed to once (which is the case for addFields), which again is a poor approach

unique axle
#

"makes much more sense" is much less of a personal opinion than you make it out to be, that point is about grammatical implication through how language works.
"This method allows you to add multiple fields" is implying that a single field is also okay, that is just how plurals work, you can say "we need more developers" and just getting a single one is also fine for now
"This method allows you to add a field" is implying that it only takes a single field, you cannot say "we need one more developer" and possibly think that implies there is enough space for more than one in the team

#

p.s.: im not gonna reply to this or really view it as I already made my point and have nothing much else to say, plus you probably couldn't change my mind anyways 🤷‍♂️
is always a lovely stance to bring, when you went through the effort of sharing your stance, ngl

copper laurel
#

I dont know why any of you are bothering to respond to someone who criticised the current arguments as being opinions, then gave an entirely opinion based argument, then openly stated they weren't going to listen to anything that might change their opinion

icy trout
#

Are there any plans to fix (improve) the undocumented pitfalls of autocomplete interactions?

[
  { name: 'for', type: 'USER', value: '163646957783482370' }, // does not behave as expected as 'user' is missing from the object
  { name: 'action', type: 'STRING', value: 'add' }, // behaves as expected
  { name: 'product_code', type: 'STRING', value: '', focused: true } // behaves as expected
]

Although the USER type is present, getUser does not return the expected output b/c it it missing the resolved user field.
(this should really be documented, I had to look at d.js source to find out why it was returning null)
https://github.com/discordjs/discord.js/blob/stable/src/structures/CommandInteractionOptionResolver.js#L193
I had assumed that d.js would resolve the user id into a user under the hood when resolved was not present.

A lot of the head scratchers here could be resolved (pun intended) by updating the documentation to reflect reality :)

copper laurel
#

Yeah it sounds like these issues are an oversight as a result of re-using the CommandInteractionOptionResolver and assuming the types would be the same

unique axle
#

@icy trout if this is not yet an issue on GitHub, please make it one, so we can track completion

icy trout
simple pagoda
#

with the #7584 builders PR changes, would it be better for all builders to have a constructor where you can pass a raw object into it, for consistency? currently, only the EmbedBuilder and UnsafeEmbedBuilder support using new Embed(rawEmbedData), however the other builders lack such a method. would it be better to have these on all, or remove it from embed, just to keep builders consistent.

just for clarity, some examples:

- let mySlashCommand = new SlashCommandBuilder().setName("mycommand").setDescription("example command");
+ let mySlashCommand = new SlashCommandBuilder({ name: "mycommand", description: "example command" });

- let myButton = new ButtonComponentBuilder().setCustomId("testbutton").setStyle(ButtonStyle.Primary).setLabel("Click me!");
+ let myButton = new ButtonComponentBuilder({ customId: "testbutton", style: ButtonStyle.Primary, label: "Click me!" });
dawn merlin
simple pagoda
#

oh do they? must've missed that, apologies

#

i did double check interactions and they don't appear to have it, unless im mistaken again

dawn merlin
#

Not interactions but the builders

#

Interactions are only created internally

simple pagoda
#

yeah thats what i mean, things like SlashCommandBuilder

dawn merlin
#

Oh yeah they don’t

simple pagoda
#

is there a reason why they wouldnt, or just wasn't added/overlooked?

dawn merlin
#

Probably overlooked

tacit crypt
#

Not overlooked

idle cypress
#

Now that modal pr had been merged can we expect 13.7 tonight?

analog oyster
#

the modals pr for v13 was not merged

idle cypress
loud jayBOT
#

pr_open #7431 in discordjs/discord.js by monbrey opened <t:1644395181:R> (changes requested)
feat(modals): modals, input text components and modal submits, v13 style
📥 npm i monbrey/discord.js#modals

analog oyster
#

that was targeted at the main branch

#

aka v14-dev

opaque vessel
void rivet
#

Sure I'll look into it when I'm back home

outer raven
#

seems like the method internally calls ChannelManager#fetch which can't return null, which is what I find odd

opaque vessel
#

I may be missing something but I'm not sure why it calls ChannelManager#fetch()... and it looks like the parameter calls there are incorrect - second parameter is an object

outer raven
opaque vessel
#

It looks like we future-proof channel types such that if you fetch a new channel type and we don't have support for it yet, the fetching returns null

#

So I guess in this case, it cannot return null... also @ruby terrace maybe you can look into that too^

#

Although when forum channels come out and we don't have support for it yet & it's being fetched, it will return null in that instance it seems

outer raven
#

Shouldn’t it return a Channel instance of type unknown?

#

And tbh no other fetch method has null as a possible return value afaik

ruby terrace
#

ChannelManager#fetch returns null when the channel type isn't known (unknown is only used if you construct a Channel directly, not through .create) OR when the guild is not in cache (with a notable exception that doesn't apply here)

outer raven
#

That should probably be changed though right? It’s such an edge case that having it typed as null solely for that is a bit annoying

ruby terrace
#

its not supposed to be an edge case, and you can't just yank out a valid type

outer raven
ruby terrace
#

if you want to take it to that, you need to check the type of the returned channel because you can technically fetch any channel via the thread manager

outer raven
#

Yeah that’s true

#

Maybe it should reject the promise whenever a non thread channel is fetched

outer raven
#

The documentation workflow should probably pull before pushing to avoid CI failing when many commits are made at once

dawn merlin
outer raven
#

Ah I hadn’t heard about that, sounds like it’ll fix it yeah

#

But still, it’s a small thing that can prevent issues for now

#

And it shouldn’t create other issues

analog oyster
#

pulling at that stage is probably just going to cause conflicts

vernal rose
void rivet
sand thunder
#

I sincerely apologize if this is better suited for issues, but... has there ever been plans to work on a built-in framework/command handler for discord.js like discord.py has?

One of the main issues I have when creating new bots with discord.js is having to spend hours creating a framework for handling commands and events.

If there was a framework like Akairo built-in and updated/maintained, or even just a template that could be linked to something like npx create-discord.js-app, I think that would really improve the library.

visual hornet
#

isn't that just sapphire (#useful-servers)
haven't really used nor looked into it so not sure if that's what you're looking for, but iirc it's a v13 commando which i think i recall was a framework for commands?

sand thunder
visual hornet
#

probably, it's maintained by djs contributors

sand thunder
#

Huh, I used to ask here pretty frequently if Sapphire supported slash commands and people said no, so I assumed that it wasn't actively updated. Now that I look at it again though, it looks like it does support them.

My bad, sorry for wasting your time!

visual hornet
#

probably just took a while to get added

copper laurel
#

We don't want to "build in" a command handler in the same way that discord.py did. We're a much more foundational API wrapper, while discord.py includes a lot of abstraction and additional features. That's not the approach we take.

Sapphire is our recommended framework - while it may not always be perfectly in sync with Discord/discord.js it is the actively maintained framework, by discord.js contributors, and is the only one that properly supports v13

Regarding your final suggestion, you can always keep your own private boilerplate repo of your template/framework and fork it into new bots or similar

tacit crypt
mighty sequoia
#

in my testing, lastmessage is always null for threads in 13 latest

dawn merlin
mighty sequoia
#

yes

#

doing const msg = await threadChannel.messages.fetch({limit: 1}) works

opaque vessel
#

Not able to reproduce that

#

You need the proper intents and must ensure that the thread actually has a last message id. If there is a last message id & the message isn't deleted & the message is cached, make an issue

vernal rose
#

https://github.com/discordjs/discord.js/pull/5367
ig this pr should be recreated because of these 2 issues. The first one was opened recently

https://github.com/discordjs/discord.js/issues/7571
https://github.com/discordjs/discord.js/issues/5350
#950042305702817842

But I'm not sure what space said.

is this is what he said?

 if (this.status === Status.WAITING_FOR_GUILDS && [WSEvents.GUILD_DELETE, WSEvents.GUILD_CREATE].includes(packet.t)) { 
   this.expectedGuilds.delete(packet.d.id); 
   this.checkReady(); 
 }
wicked bronze
#

Am I allowed to send suggestions for D.js in here?

unique axle
#

feature suggestions generally go on the github in the form of issues so they can be tracked

outer raven
#

I know there haven't been a lot of PR merges lately but I've noticed that when there are, they are usually shortly after 12pm GMT (the time at which a dev release is published) so I was thinking that maybe it would be useful to change the schedule to try to make a dev release at 4 or 5 pm/am since that's usually after PRs are merged so that more features could be shipped faster, what do you think?

outer raven
#

@wild flax since you’re the one who manages that, what do you think about this ^^

outer raven
#

the collector filter function emits with a collection of all the collected items so far but the typings don't seem to represent this, is this a bug?

unknown.png
void rivet
#

could we use an array instead of a collection on collectors' end events?

since (for reaction collectors) emoji ids/names are used as collection keys, for multiple collections on the same reaction, the collector would only hold one of them since the keys are the same

copper laurel
void rivet
#

and yes now that i think of it an array of MessageReactions doesn't fix it either,it's not that simple
i don't know what would be ideal

copper laurel
#

I don't think so but I'm not certain

void rivet
#

well i'll test it when i can then
it should be pretty simple, just need to check on the collection, one of the .users contains the bot who should be filtered out

vernal rose
void rivet
vernal rose
void rivet
#

that is how djs caches all the guilds to begin with

void rivet
#

even according to types memberCount isn't documented to be null

visual hornet
#

make sure you have the proper intents as well?

vernal rose
#

9 is giving memberCount

visual hornet
#

0 + null should just be 0 though

vernal rose
#

Idk how it's giving null lol

analog oyster
#

I had that issue too when sharding, unsure how it happened so I just added || 0 to the memberCount and forgot about it

visual hornet
#

could you maybe try changing the reduce function to (a, b) => (console.log(b.memberCount), a + b)

vernal rose
analog oyster
#

Yeah

vernal rose
#

Lemme try

analog oyster
#

Might just be because of unavailable/ghost guilds

void rivet
#

perhaps you can add a filter for it beforehand?

mighty pebble
#

How do you view the name of subcommand that was run

visual hornet
mighty pebble
#

oh god wrong chat sofry

void rivet
analog oyster
#

thats not even the right type for it

#

it doesnt have any of those methods

void rivet
#

there is a Components class in ./util/Components that has a createComponent method

i think it was an oversight since createComponent got renamed to createComponentBuilder i am unsure which one you want to stick with since it is the djs package

analog oyster
#

the components class in djs and createXBuilder methods in builders serve different purposes

void rivet
#

so the types should change to createComponent, right?

analog oyster
#

yes

#

or removed entirely, depends on which path you want to take

#

since its not actually exported

void rivet
#

yeah i'm not sure on that either on whether or not they want it exported
it didn't make sense to me to use the word Builder in the djs package

#

but all this aside, there are still bugs with builders
in builders, there are cases where the createComponent -> createComponentBuilder change hasn't been dealt with, i mentioned that in rodry's pr

analog oyster
#

no me, and it shouldnt use that

#

above your comment in rodrys pr

void rivet
#

i'm talking about builders though

analog oyster
#

wdym, builders uses ts, that wouldnt happen there

#

createComponent is just being used incorrectly in that one file i mentioned

void rivet
#

okay no i think i was checking outdated code on phone 🤔

#

so in the end the question is just
should the Components class from util be exported from djs?

analog oyster
#

it doesn't have a @private thing in the jsdoc so i dont see why not

void rivet
#

yeah but i'll confirm it and let rodry make a pr

flint ledge
#

how even does the user detection work? like if u put a user token, and what doesnt the other libraries do that allow ppl to use user tokens? for example eris

tacit crypt
#

No library is allowed to support user tokens anymore

#

And they haven't been for years

#

Eris is removing it too

#

And as for how user detection works...we don't know. It's Discords secret

#

Also not related to d.js

outer raven
unique axle
#

that'd be my proposal, should we go with an event at all
(arguably this can easily be done right now by having a filter with side effects)

outer raven
#

it can but like I said in the PR, a filter's purpose should be to simply return a boolean and not do other tasks and this would make people's code more organized

#

well I like that idea, but idk if I should commit it or wait for others to give feedback on it

unique axle
#

i think i agree, not a fan of functions with side effects, really

outer raven
#

ill wait until tomorrow at least to let other people give their opinions or react to your comment

#

also about the descriptions of the event and collection on the docs, should I keep filtered out or change to ignored?

unique axle
#

i would personally probably go with the most straight-forward and least ambiguous, which is "collected" vs. "not collected"

outer raven
#

alright, I have the commit ready for tomorrow then

unique axle
#

on "notCollect" is a super shit event name though, unfortunately

outer raven
#

lmao yeah

minor venture
#

Is this worth fixing?
Current: <Collection>.first(-1) => <Collection>.last(1) => ["returnValue"]
Current: <Collection>.first(1) => ["returnValue"]

<Collection>.first(1) === <Collection>.first()
But: <Collection>.first() => "returnValue"

Should .first(1) or .last(1) not return a string?

Fixed: <Collection>.first(-1) => <Collection>.last(1) => "returnValue"
Fixed: <Collection>.first(1) => "returnValue"

opaque vessel
#

I would say that is intended behaviour. You could be passing a dynamic number which may be 1 and still expect an array result. This breaks that behaviour

real jetty
#

testing the bot is hard you've to do it in discord in real app is there a way i can do fake bot ? in discord.js like emiting fake events but in easy way ?

minor venture
outer raven
dawn merlin
#

I’ve been thinking of making a mock gateway server for testing djs

patent halo
#

any plans to ditch commonjs and just use es modules?

golden mortar
#

... hopefully not

copper laurel
void rivet
dawn merlin
#

Sure

void rivet
#

okay then, removing Embed.setColor

loud jayBOT
outer raven
#

That function is clearly adding functionality on top of the builder function

void rivet
#

setColor is a method that shouldn't exist on Embed, it should exist on the builder

#

none of the embed modifying methods exist on Embed other than this

outer raven
void rivet
#

okay so let's make it less confusing,
setters should be on EmbedBuilder, not on Embed, that's the whole point of 7584

outer raven
#

Got it

hot echo
#

In GuildMemberManager#_fetchMany, it has this line for fetching with shards: this.guild.shard.send({
When I try to fetch guild members from a guild that isn't on the same shard, this line errors because this.guild.shard is undefined.
Would it be better to change this line to this.client.shard.send({ instead, or would that break something I'm not aware of?

#

if no one explains exactly why i'm wrong within 2 hours imma make the pr

#

Here are some steps to reproduce the issue:

  1. Make a bot with members intent enabled and add it to 2 guilds
  2. Shard the bot with a ShardingManager and set the totalShards to 2 (This is so each guild can be on a different shard, in reality my issue takes place on a bot that will have ≥2 shards anyway)
  3. On ready, try fetching one of the guilds by its id and then fetch the members. client.guilds.fetch("insert_guild_id_here").then(guild => guild.members.fetch().then(console.log))

It should be able to fetch with no problems on both shards. However, on the shard that does not include the guild, it will throw an error because this.guilds.shard is not defined because the guild is on the other shard.

opaque vessel
#

You don't have the GUILDS intent?

hot echo
# 
['GUILDS', 'GUILD_EMOJIS_AND_STICKERS', 'GUILD_MEMBERS', 'GUILD_MESSAGES', 'GUILD_MESSAGE_REACTIONS', 'DIRECT_MESSAGES', 'DIRECT_MESSAGE_REACTIONS']

My intents

#

(yes, my bot is verified/whitelisted for the members intent)

#

the error stack:

TypeError: Cannot read properties of undefined (reading 'send')
    at /Users/myname/Documents/Projects/Bots/node_modules/discord.js/src/managers/GuildMemberManager.js:422:24
    at new Promise (<anonymous>)
    at GuildMemberManager._fetchMany (/Users/myname/Documents/Projects/Bots/node_modules/discord.js/src/managers/GuildMemberManager.js:419:12)
    at GuildMemberManager.fetch (/Users/myname/Documents/Projects/Bots/node_modules/discord.js/src/managers/GuildMemberManager.js:177:31)
    at module.exports (/Users/myname/Documents/Projects/Bots/bots/Cinnamon_Beta/events/ready.js:49:67)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
#

gtg

hot echo
#

and however you'd get the shard id in other sharding types

slate nacelle
#

As far as I am aware will Discord just discard those requests.

hot echo
#

or do I have to fetch on one shard and then cache them in the main process (which would be an absolute pain)?

ornate topaz
#

what is the reason for you to actually be fetching the members?

hot echo
#

i need to verify that the member has a specific role in the bot's support server for their server to have a specific value stored in the database, it's part of the premium perk system

ornate topaz
#

then there should be absolutely 0 problem to just use a broadcastEval for that. no need to move caches between anything

hot echo
#

ok

hot echo
#

or does it wait until all shards are ready to trigger the ready event

ornate topaz
#

if you are doing it in ready, you could just wait until all shards spawn. you should be able to access total shard count and id of current shard. if it's last shard, call the broadcastEval

hot echo
#

i'll just do the complicated caching system that i know will work

ornate topaz
#

broadcastEval, in case you didn't play around yet, runs code on every shard.

hot echo
ornate topaz
#

?

#

anyway, this doesn't really fit this channel anymore. you should probably move to #archive-sharding if you want help with broadcastEval

hot echo
#

thanks for the help but i already know how broadcasteval works and why it won't work in my scenario and that it would take too much typing to explain it and i'm on mobile rn

outer raven
#

so to answer your question literally, no I can't 😅

real jetty
void rivet
#

@dawn merlin i wrongly believed that EmbedBuilder.setColor had the new implementation, could you redo https://github.com/discordjs/discord.js/pull/7593
but instead of for the Embed class, do it for EmbedBuilder on djs's exported EmbedBuilder specifically?
or should i do it later?

dawn merlin
#

Depends, there's no rush so if you feel up to it feel free

void rivet
#

yeah i can do it a few hours later, it'd just be a clone of your pr just for a different class

loud jayBOT
outer raven
#

Is there an interface in the djs docs for this type?

unknown.png
alpine bough
#

currently, the EmbedBuilder class in index.d.ts has this error in setColor method
is it worth opening a PR do just remove overrive keyword?

unknown.png
outer raven
#

try reinstalling them

alpine bough
#

true, thanks 👍

void rivet
#

since the re-exported djs EmbedBuilder's setColor now takes in multiple types of input
are there any plans for the djs exported builders to use the Util methods and allow multiple input types like how it used to before?
like perhaps the setEmoji methods 👀

dawn merlin
loud jayBOT
void rivet
#

are there no other builder methods that used to use Util internally to resolve a data?

dawn merlin
#

The only other places it’s used is for verifying input and resolving a string to an enum type (which we purposely don’t support)

void rivet
#

yeah i know, that's why i mentioned resolve a data specifically
but i'll take that as after the setEmoijs are done, there aren't any similar cases

quiet viper
#

Discord is rolling out Text-in-Voice. Since the voice channel type will stay the same, won't it have a effect on the messageCreate Event?

copper garden
#

It would affect the Message class most likely, mainly its channel property type

quiet viper
#

I heard from some users that their bot crashed. Let me gather more info.

slate nacelle
#

Stable should be fine. v12 and v11 won't though.

void rivet
# copper laurel I don't think so but I'm not certain

it does

  const mess = await (client.channels.cache.get("id") ).send("mess");
        await mess.react("😂");
        await mess.react("🤣");

        const collector = mess.createReactionCollector({"filter": (reac, usr) => !usr.bot && ["😂", "🤣"].includes(reac.emoji.name ), max: 1});
        collector.on("end", (collected) => console.log(collected.map((e) => e.users.cache)));
```it does include the bot's initial reaction, i don't think there's any way to get only the collected data, it gives you all the cached users, not just the collected ones, which i don't think would be intended
#

i again don't know what would be the ideal solution
i don't think you want to start with an empty clone of the MessageReaction
i don't know how you even only get the collected reactions and just the collected reactions

stark wolf
#

there are just 5 seemingly unrelated issues on there Thinkeng

#

all opened by the same guy

warped crater
#

*gal

#

and this "same gal" is one of the core maintainers :p

#

the issues are related though since the ts rewrite is.. a full rewrite, and those are desirable things to have but that are difficult to accomplish as the library is right now, if I had to guess why those 5 right now

stark wolf
stark wolf
#

and it would really only benefit the maintainers i guess

copper laurel
#

Yes and no

#

Proper typescript rewrite should create much more robust experience for all TS users of the lib

#

And all contributors, not just maintainers

tacit crypt
#

And even for the JS users, as typings would be always up to date and accurate with the code

analog oyster
#

Not sure if this is known or not but the seems like the publish dev workflow is not working. The last commit was done 3 days ago and the last release was 4 days ago
its stuck in this commit

unknown.png
copper laurel
#

So can we blame Rodry? (jk)

#

We know, I assume someone will look at it soon

inland lotus
#

I know it takes time, but is the modals (v13) pr still being worked on or awaiting review/merge

copper laurel
#

I'm on holiday

#

That's why I haven't rebased it lol

#

I'll be back home on the 25th

inland lotus
#

alright, have fun

steady oasis
rough roost
warped crater
#

how do you see this "handled"

rough roost
#

throw an error

dim crown
#

I'm curious for the new 13.7 update, especially I'm in need of the native stable release for modals. Would it be the last minor update so bot developers can move on with the major update soon?

real jetty
#

its the last minor planned currently, yeah

outer raven
#

Shouldn't interaction.options.data hold the options of the subcommand whenever there is one? It's a bit annoying to have to first find the subcommand when it's the only option and only then be able to get its options

copper laurel
#

Then it wouldnt be the raw data though

#

Or is it already promoted up... I honestly cant remember anymore

#

okay no it isnt

outer raven
copper laurel
#

I mean... technically no, I agree. But that's the "not raw data" use case

#

So you want to get the subcommand via a resolver method, then access the raw data in a hoisted fashion only for that subcommand instead of resolver methods?

outer raven
#

8 options from which only 2 are required

outer raven
#

so the color BLUE should resolve correctly

unique axle
#

did you even read what i said?

outer raven
#

I did read it all

#

you said it's not found because of the casing difference

#

but there is no casing difference

unique axle
#

i said i can reproduce that the color does not resolve with that code on the dev version

#

with an explanation as to why that may be the case

outer raven
#

but the bug report is from v13 what

unique axle
#

...

vernal rose
outer raven
#

doesn't make much sense to talk about v14 code if the bug report is from v13

warped crater
#

you.. clearly didn't read

#

souji simply explained why such an issue would arise on 2297c2b and that he could

somewhat reproduce

#

and even mentioned

I cannot reproduce this on either the linked stable version [...]

copper laurel
outer raven
copper laurel
#

I mean I generally agree with you except I don't think we should ever be modifying that property since it's the raw data

#

So leave it alone

#

I'd just suggest making hoistedOptions public read-only

outer raven
#

having both data and hoisted options as public props seems redundant but sure that could work ig

real jetty
#

is it intentional that the discord.js/typings/ folder is not exported in the main index file?

wild flax
#

yeah

real jetty
#

ah okay

latent idol
#

When will v12 be completely finished?

cursive jackal
outer raven
#

Answer is: in about a year

tacit crypt
#

v12? That ones deprecated to the moon and back
v14? Eventuallytm_new

outer raven
#

according to discord

short cairn
#

Is there anyway to run cleanup code after an interaction has timed out?

unique axle
#

what sort of interaction timeout are you referring to?

short cairn
#

maybe interaction isnt the right word, maybe command timeout? So when you issue a command and it listens for an interaction there is a timeout (not sure what the default is) but you can defer this.

#

basically im wondering if there is a way to hook into this timeout, maybe with a callback? does that make sense?

unique axle
#

you mean when the interaction fails?

#

you have 3 seconds to respond to an interaction
you can defer this and then have a valid token to update it for up to 15 minutes to resolve the "thinking..." state

void rivet
#

There isn't a djs exported ModalBuilder that accepts camelCase properties
is this intended?

mighty bough
#

we should be able to do guild.channels.resolve(channelMention)

opaque vessel
#

Would rather the user parse the input, not a fan

copper laurel
#

Yeah that's not what resolve is for, does not do regex parsing of ids. Expensive operation

mighty bough
copper laurel
#

Slow. Not very performant

wet spruce
#

hi, quick question: is there a roadmap for specific releases so users & contribs can know what needs to be done and when to expect a new release?

outer raven
#

Nope not really, new prs get added to a milestone which u can follow tho

outer raven
wet spruce
hollow stirrup
#

@tacit crypt

#

I only have these 2 left

#

I deleted those logs

analog oyster
#

the first screenshot includes your bots token in case you're not aware

solemn oyster
#

@hollow stirrup ^

hollow stirrup
#

shiiiit

warped crater
#

also might not want to show session IDs either

#

people can resume with it but without your token

#

and just start listening to that shard's events

#

even gives room for grabbing your token

hollow stirrup
#

@warped crater now it doesn't matter all are invalid now

#

Token, session id

oak quail
#

imo versions earlier than 13.3.1 should be deprecated due to the TiV crash

tacit crypt
#

you need the session id and the token

warped crater
#

oh

#

memory trolled me

void rivet
#

why doesn't djs type Events even though it exports it?

opaque vessel
void rivet
#

no you're not, i reached the wrong conclusion based on a question a user asked

opaque vessel
#

[:

outer raven
#

Apparently you can't construct a link button in an object and send it in a message but I can't quite figure out why, does anyone know the cause for this? You can make non link buttons just fine btw and the error is the one attached and I also attached the button object I'm working with

unknown.png unknown.png
#

found this while adding the tests you asked for @tacit crypt, I'll commit with this line commented out as this seems to be an issue in discord-api-types so I'll leave that up for someone else to figure out

tacit crypt
#

Looks like clashing versions of -types

outer raven
#

hmm my deps are up to date though

#

I could update to 0.30.0 tho

#

updating it didn't fix it unfortunately

ruby terrace
outer raven
ruby terrace
#

The inferred type is not narrowed all the way down

#

Oh, as const on the button style directly maybe ?

#

Don’t remember if the buttonstyles enum is const or not

dawn merlin
#

It’s not

#

But that shouldn’t affect types anyways

outer raven
#

there are no const enums thankfully

outer raven
#

but we shouldnt need to do that

ruby terrace
#

Yeah, then that cast should

outer raven
#

because it works for non link buttons

dawn merlin
#

Sounds like a type is only accepting a subset of valid button styles hence why link doesn’t work directly

ruby terrace
#

Well, yeah that is narrowed to link only

dawn merlin
#

Also don’t think it’s a Dapi types issue most likely djs types since we made changes to ActionRowData recently

outer raven
#

but the types for raw button objects come from discord-api-types

dawn merlin
#

They don’t they come from ButtonData

outer raven
#

which is this, looks like it should work

unknown.png
dawn merlin
#

Probably something small causing the issue

#

What happens if you put style in the BaseButtonComponentData

outer raven
#

as a type generic or a property

dawn merlin
#

Just as a style: ButtonStyle

errant basin
#

do you know why there is only 5 styles of buttons?

dawn merlin
#

Bc that’s what the api allows

outer raven
errant basin
raven juniper
#

That's not a discussion for this channel

errant basin
#

ok

dawn merlin
#

Hmm I wonder if the v13 types are doing anything different

outer raven
#

cant test on v13 rn but I think they'd be fine because the issue might be because we use numbers

#

and TS isn't good with excluding numbers from enums

#

or so I've heard

dawn merlin
#

We’re not using enums as values here we’re using their types

#

What happens when you don’t use exclude and manually list the interaction button styles

outer raven
dawn merlin
#

Now im really interested if this works on v13

outer raven
#

can you test it?

dawn merlin
#

Yeah when I get home

outer raven
#

alright

dawn merlin
#

I'm not able to reproduce this on v14:

const row = new ActionRowBuilder<MessageActionRowComponentBuilder>({
    components: [
      { type: ComponentType.Button, style: ButtonStyle.Primary, customId: 'test', label: 'test' },
      { type: ComponentType.Button, style: ButtonStyle.Link, url: 'test', label: 'test' }
    ]
  })

  if (channel.isText()) {
    channel.send({ components: [row] })
  }
outer raven
vital wind
#

Hello guys how do i test my bot any library?

real jetty
vital wind
#

thanks

dawn merlin
outer raven
#

it doesn't for me tho Thonk

#

i mean that exact code snippet works but the second I put it in a variable it doesn't

#

can you try that?

dawn merlin
#

it works in a variable as long as I explicitly set the type to (Required<BaseComponentData> & ActionRowData<MessageActionRowComponentData | MessageActionRowComponent>)

#

which is the same thing you have to do for v13

outer raven
#

but thats not ideal

#

you shouldn't have to explicitly type it

#

specially not that monstrous type

dawn merlin
#

well yeah the type name can definitely be reduced, but there's no avoiding not typing it at all. TS can't infer the type prop enough by itself

#

in v13 it's reduced to string

#

and in v14 it's reduced to ButtonStyle

#

both aren't specific enough

outer raven
#

hm aight then

#

Why doesn't GuildScheduledEvent#fetchSubscribers() include member data by default when other endpoints with optional data always include it unless the user specifies they don't want it?

#

Also is there a reason why those users aren't cached? They're sent through the events

rocky owl
#

Any idea on how to make a warn command? Would it be better to have a database which have a general array that includes elements, that elements also include the user id and the quantity of warns

#

or is a better idea to have an individual array for every user

ripe gate
runic bear
outer raven
copper laurel
analog oyster
#

i assume so, basically the same as the setEmoji method but on the constructor

copper laurel
#

Then probably yes, the constructor should behave the same

outer raven
#

alright, will PR

short cairn
#

Hey folks where is the best place to get updates on v13.7?

ornate topaz
short cairn
lament shoal
#

not sure if it goes here but the last message in #769862166131245066 is a bit outdated since you can edit your bot profile picture and name in the dev portal again

outer raven
#

Proposal - revert PR 7584

lofty beacon
#

hey, i've been told something about a new sharding client being worked on. is that still being worked on? if it is, i have some ideas to bring to the table about some perf things

outer raven
lofty beacon
#

right, because i saw something called discord-hybrid-sharding that implements some theoretically pretty cool ways of saving memory wehn sharding

outer raven
#

thats none of our business

lofty beacon
#

nvm then

tacit crypt
#

When in doubt, if you see opportunities for improvements, bring them up in the PR.

#

For instance some brought up ws related improvements already

lofty beacon
#

just curious :p

tacit crypt
#

check the PR

#

:P

lofty beacon
tacit crypt
lofty beacon
#

the shard one that was linked above?

#

ah right

#

last commit a month ago dead

#

should we thread up about something regarding clusterning shards? @tacit crypt - i think it would be a good fit for your pr potentially

tacit crypt
#

hmm?

lofty beacon
#

well

#

there is some prior art

#

lets just make a thread

#

clustering shards

inland panther
#

Is the reason for why something like a MessageEditCollector doesn't exist a lack of practical use cases, or would it not be advised to use such a collector for some other reasons?

copper garden
#

Most likely a lack of practical use case, even before the message content intent was a thing

ornate topaz
#

on top of that, i believe it also isn't that hard to implement using just messageUpdate event and checking for message id to warrant it being a Collector

unique axle
inland panther
ornate topaz
#

Technically, collecting messages or reactions manually in messageCreate or messageReactionAdd isn't particularly hard. You just need to check relevant ids (channel id and message id, respectively). There's also countless ways on how you would manage the handling of multiple things to track, and adding/removing things you track dynamically.
The reason as to why MessageCollector and MessageReactionCollector exist is that the commonness of wanting to get some additional data from user in the simplest forms of sending another message or having user react to a message "outweighs" the relative ease of own implementation. And it also comes with few things that would make it tricky or convoluted to implement, especially if you don't necessarily know how to perform such stuff manually (like dispose, max or any time related param)

Edits however are quite rare form of giving your bot more data. Hypothetical MessageEditCollector would most likely be also scoped to only a single message, so it wouldn't be useful for stuff like command edits, where you would have to create collector for each and every message your bot receives. There's also the fact that edits are limited compared to just sending new message - think attachments or getting outside of character limit. And you can only press up arrow so much without resorting to having to constantly right click -> edit.

(Also, despite MessageCollector and MessageReactionCollector being a thing, you still should just use events instead of long-running or endless collectors for stuff like reaction roles or "send message here to verify" things 🤷‍♀️)

real jetty
#

Thonk would it be possible to override all of discord.js's collection based cache for redis without needing to fork and change the lib?
The only issue I am thinking will incur is redis is async collections are !.
Trying to create a centralized cache solution for a project.

ruby terrace
real jetty
#

Hm interesting, I may very well take the partial packages and just contruct my own wrapper at this point.

Very interesting issue though 👌

outer raven
outer raven
#

@copper laurel actually it seems like those methods don't allow null in their types 🤔

copper laurel
#

Well it wasn't necessary prior to your change (though arguably should have been possible to remove the author entirely with null)

outer raven
#

you can remove the entire object but not specific props within it

copper laurel
#

And .setAuthor({ ...embed.author, iconURL: <new URL> }) will work after the getters PR right?

tacit crypt
#

There are so many PRs touching builders I don't even have enough courage to submit a PR that makes builders consistent with interaction builders

golden mortar
#

djs should get rid of builders and make it an optional package for ppl to install and use

ie. message.embeds would return an array of APIEmbed and a user would do something like ```js
const embeds = message.embeds.map(e => new UnsafeEmbed(e));

if they wanted the structure
#

rather than the library constructing builders for people, it should just return the direct api data and have the user construct the builder themselves.

dawn merlin
#

It doesn’t return builders anymore

#

It’s a class that just holds data now

golden mortar
#

cool 👍

dawn merlin
#

Might be wrong but outside of the extended builders re-exported by djs. It doesn’t use builder code anywhere for serialization anymore

visual hornet
#

i asked this before but i don't believe i got a response

For XCollector.endReason, why are max[X] options treated as [X]limit?
Shouldn't they be max[X] just for consistency with the option that triggered them? Or at least be documented?
https://github.com/discordjs/discord.js/blob/main/packages/discord.js/src/structures/MessageCollector.js#L103
https://github.com/discordjs/discord.js/blob/main/packages/discord.js/src/structures/ReactionCollector.js#L164
https://github.com/discordjs/discord.js/blob/main/packages/discord.js/src/structures/InteractionCollector.js#L182
also why doesn't endReason seem to acknowledge the time and idle end reasons

earnest sedge
#

I can't seem to find the documentation for the send() method in the Channel object. It works though :/

#

should I do it differently?

visual hornet
earnest sedge
#

❤️ (for some reason I can't react on your message)

real jetty
#

does anyone know

#

a maintained version of djs/commando right now

#

like a fork

#

i need to support this legacy bot but cannot get rid of some of the commands

inland lotus
#

sapphire

copper laurel
#

No, commando is not maintained

real jetty
#

alright thanks

wild osprey
#

how does djs get to know if <GuildMember> is bannable, moderatable,kickable etc

unique axle
#

you can look at the source code, it's a chain of permission and highest role position/owner checks

wild osprey
#

ty

honest barn
#

any chance #7731 can get reviewed soon? it has been sitting there for 11 days with no reviews from maintainers

calm urchin
#

Hey, I have a simple question, since the v14 is coming soon. It’s true that the v12 will definitely end this month if?

visual hornet
#

apparently discord pushed back the update so i guess not
v11 and v12 dying are not in our control

calm urchin
#

After it doesn’t matter if it ends, but it’s so sudden

#

because I still have my site that is under v12 and if it ends this month if it is hot to pass in v13

ember steeple
#

v12 will die in early 2023

calm urchin
ember steeple
#

it was really announced

calm urchin
#

do you know where the ad is?

#

please

ember steeple
calm urchin
inland lotus
#

scroll in api announcements and you will find it

calm urchin
ember steeple
#

yes

calm urchin
#

but how do we know which api and used on the versions of discrdjs?

ember steeple
#

read source code on github

calm urchin
#

well I already looked before but it gives the api 10

outer raven
#

v11 is api v6 and v12 is api v7

analog oyster
#

both v11 and v12 use rest v7

outer raven
#

Ah ye nvm

calm urchin
molten jungle
#

Is it worth making a PR?

inland lotus
#

probably not, since if you want to unset the content you set it to null iirc

molten jungle
#

Well if it's false it seems you get an error saying "Message content must be a non-empty string." even though it can

#

Also just above it content is defined to be an empty string so empty strings can still be returned from that function

#

Tbh can't believe I'm the first person to encounter this bug lol. You should be able to send a message with embed data and an empty string. Works if you make a raw api req

inland lotus
#

well, most of the time you just do { content: null, embeds: [embed], ... }

molten jungle
#

But why can't you do { content: '', embeds: [embed], ... }?

#

Still valid but it errors

inland lotus
#

imagine you have a string variable and in some case its an empty string, you're unintentionally removing the content of the message which results in the error.

while if you pass null, you're explicitly telling it that the content must be removed.

thats my opinion, ill leave the rest to the maintainers

molten jungle
#

I mean I agree that in terms of practice it's probably better to make it explicit

I'm not 100% sure what this libraries policy is for API compliance but it would make more sense from a "will this work" stand point to allow empty strings as a raw api call will allow it? Both are falsy values anyway and in terms of just that function it literally just converts it to an empty string if the content is null but then doesn't allow just an empty string to be passed in? Seems a little counter intuative imo

#

Do you think it's worth a PR to let people discuss on github?

inland lotus
#

sure

molten jungle
crisp thicket
#

would it be possible in the future to have client.channels.send(id, message) similar to client.users.send(id, message)? is there something in the REST api that would prevent that?

ornate topaz
visual hornet
outer raven
ornate topaz
#

v14 docs don't seem to have ChannelManager.send()

outer raven
#

Actually it seems like it wasn’t ?

#

Weird, that should’ve gone in the manager methods pr

#

You can PR it if you wish, probably missed it by mistake

ornate topaz
#

#7300 did not add UserManager.send(); that was done separately during move of createDM() to the manager in #7087, which in turn allowed sending DMs without need to fetch users.
And personally not sure about the fact that while every user has a send method, not every channel is able to have messages being sent to it, and library itself clearly defines that in code

#

and weren't channels defined as always cached for discord.js?

crisp thicket
#

there should be a way to do it independent of shard though

ornate topaz
#

True

outer raven
#

You could always have the method and let discord error if it cant receive messages

crisp thicket
#

hacky, but await new TextChannel(undefined, {id}, client).send(message) seems to do what i want

golden mortar
crisp thicket
candid crest
#

Does @discordjs/rest handle rate limits?

dawn merlin
#

Yes

ruby terrace
# crisp thicket there should be a way to do it independent of shard though

I always forget this is a problem too. djs is still quite dependent on channel + guild cache, but for sharding it doesn't need to have them on shards that don't handle their respective gateway events (duh), however it would be nice to be able to fire off a rest based request on any such thing from any shard

molten jungle
# ornate topaz What the function does internally might come out purely from how API works. Does...

Just tested and the API does allow you to pass null and undefined as well as an empty string to the content field. However it seems ( do correct me if I'm wrong ) that when sending an embed when content is set to null an empty string will actually be sent to the api? Surely this is not intended? If so could you explain why as it doesn't make sense to me

Thanks for the clarification about how the discord.js project operates

blazing palm
#

any hopes on throws being documented in the near future with js/tsdoc?

oak quail
#

Discord has said that they want bots to add support for text-in-voice and forums so they are ready when they release; does discord.js plan on adding and merging those features accordingly?

quiet viper
oak quail
#

well the draft tiv pr hasnt been edited since january

oak quail
quiet viper
#

But there is no official info as of now.

oak quail
#

they announced it to large bot devs and library devs in october, with access to the testing server

woeful rain
copper laurel
#

Of course we intend to. I'm not sure how else to respond to that.

#

But like always, we require some form of documentation to base it on

ruby terrace
#

Discord has been giving us confusing information recently, they don’t want us to implement undocumented stuff yet they want us to implement undocumented stuff. Seems we need some updated guidance

copper laurel
#

Yeah, if we get preview docs we can at least have a draft PR ready

oak quail
#

tiv doesn't really need docs changes

#

since the docs don't say voice channels can't have messages

#

I think the only change needed is to the permissions page and is irrelevant to djs

#

and the draft pr being stagnant for months seems to indicate a lack of interest in adding it soon

ruby terrace
#

Or it means it’s been basically ready for months pending a release

oak quail
#

shouldnt it be merged if it's ready

ruby terrace
#

No because it’s not documented

tacit crypt
#

There's nothing to document about it really other than "hey look you can send messages in voice channels now neat"

opaque vessel
#

Makes me wonder if there even is supposed to be a pull request to document it

#

Or they were trying to tell us to implement it all those months ago

oak quail
#

the work many of you did to update clients was essential because we wanted to make sure bots could be updated well ahead of launch.

oak quail
#

the docs don't say that voice channels dont support messages

ornate topaz
#

wouldn't that also mean that you can send messages to categories?

ruby terrace
# oak quail yeah, "documented" means nothing for this as I said multiple times so idk why pe...

well, there's several things that need updating (granted some that need updating from news channels and threads too lol) https://discord.com/developers/docs/resources/channel#modify-channel-json-params-guild-channel and https://discord.com/developers/docs/resources/channel#create-message are great examples, suspect here is this line in particular (very outdated unless guild text is suddenly a group of channel types instead of a channel type). I also suspect a larger rework of the channel page is necessary here but that's not relevant

unknown.png
#

if we just implemented and merged TIV when we saw "oh hey, messages can be sent in voice channels now" only for discord to not ship the feature, we'd have some big issues

oak quail
#

what issues?

outer raven
#

Probably the same issues that came when djs released threads ahead of time 🤔

mighty bough
#

is there a reason for one being named ChannelType and one being named ChannelTypes?

unknown.png
copper laurel
#

Historically yes, one being a string literal type, the other being djs constants enum

outer raven
#

read the channel topic

visual hornet
solemn flower
#

Does REST Client djs has respect rate limits and queue requests?

outer raven
#

that's a requirement to be on the discord documentation list of libraries, so yes

alpine bough
#

is this a good way to simplify handlers's index?
first image is before and the second is what i could do to simplify this massive thing

unknown.png unknown.png
visual hornet
alpine bough
#

that is library-related, i'm editing library's code (the path is literally above the code)
so uh, no i guess

visual hornet
#

ah my bad, i (incorrectly) assumed the handler you were referring to was an event handler.
not sure if having just that filter would be a good idea though, as that could get tripped up if someone makes an unrelated file there for some other reason

alpine bough
#

there is no problem :)
the filter is there only because of index.js file, that is the only one that isn't a handler

solemn oyster
#

The script should be as bare as it is, removing anything may result on lower performance, lower code readability, or a change in behaviour

#

Doesn't the actual code also use sort to ensure the generated files have the same order regardless of the OS?

visual hornet
solemn oyster
#

If what you're showing me is that you're making the thing dynamic, you'll break webpack or whatever tools some people use, which has caused us some headaches. That's why it's generated and not dynamic

alpine bough
#

ah ok, now i understood
thanks for the explanation :)

alpine bough
outer raven
alpine bough
#

sad 😢

golden mortar
wild flax
#

Oh damn diagnostics channel is nice

#

Is this an observable

slate nacelle
#

Diagnostics channels are indeed nice

sinful citrus
outer raven
#

is there a djs version of that builder?

#

cuz iirc that was done only for djs not builders

sinful citrus
#

yes

# 
export class SelectMenuOptionBuilder extends BuildersSelectMenuOption {
  public setEmoji(emoji: ComponentEmojiResolvable): this;
}
outer raven
#

then yeah i can do that

sinful citrus
#

thanks 😄 👍

outer raven
#

will do that for addOptions too cuz it doesnt seem to have been done

outer raven
#

my PR's CI is failing because of this test despite me not touching rest, does anyone know how to fix this?

unknown.png
#

already tried forcing it to rerun but it still failed

copper laurel
#

thats odd, I didnt have that issue doing my builders PR this morning

outer raven
#

yeah i made 2 prs and only one has this issue, no idea why

#

and it's passing locally which is also weird

#

can you try rerunning the CI one more time?

copper laurel
#

I'm not a maintainer on Github

outer raven
#

ah I thought you were

dawn merlin
outer raven
#

did twice already

#

actually

#

second time seems to have fixed it

#

first time didnt

golden mortar
#

yeah those timing tests are like flipping a coin, i just removed them in my undici pr

#

I was getting some weird results like the 2nd time being newer than the first (getting negative diff), occasionally being 0.00000ms different, etc.

outer raven
brisk remnant
real jetty
ember steeple
dawn merlin
outer raven
#

On this page https://discord.com/developers/docs/interactions/application-commands#retrieving-localized-commands Discord says that nameLocalized and descriptionLocalized is only present when a user requests a bot's commands and thus that endpoint will return the relevant name to that user, however, this is irrelevant to bots as they cannot change their locale so why was this added to djs? We could change the methods to provide with_localizations as true internally and we won't need this field as it might cause confusion

unknown.png
#

in fact there seems to be no way to pass with_localizations as true at the moment (correct me if im wrong tho)

visual hornet
#

Aren't those based on the locale of the user, though? Not of the bot? misread, mb

dawn merlin
#

It’s part of the fetch options

outer raven
#

I looked at the code and it didn’t seem to be

dawn merlin
outer raven
#

Must’ve forgotten to switch branches then

#

And that isn’t documented

#

The docs make it seem like you must always pass an id

outer raven
dawn merlin
dawn merlin
outer raven
#

The API provides that option for users only, storing nameLocalized and descriptionLocalized is simply useless for bots

#

And those fields aren’t even documented on their docs, only on the endpoint

dawn merlin
outer raven
#

The API will never send those values to a bot. If you read the description closely it says those are the names and descriptions in the user’s locale. Since this is always en_US for bots it will always be null/absent

dawn merlin
#

Well name_localization and description_localization aren't applicable to bots anyways so those being returned or not doesn't really make a difference. However the localization maps are still only sent when a given option is provided and aren't provided when the option isn't present. Djs should be following API defaults here.

#

If you think they should always return the localization objects by default that's more of something to be brought up in the ddevs server and/or github

outer raven
#

what are you talking about

dawn merlin
#

sorry description_localized and name_localized

outer raven
#

well then that's why djs should just ignore those 2 props

dawn merlin
#

it does unless provided

outer raven
#

and there's many other methods where djs hardcodes a query option

outer raven
dawn merlin
#

ok but even if it didn't it wouldn't make a difference

dawn merlin
outer raven
#

some method somewhere, it's gonna take a while to find

#

and in methods like these it makes sense, because you should want all the data anyways

woeful rain
#

Wouldn't it be better to change the partial getter to an isPartial() function like the other typeguards, and the typings would be isPartial(): this is PartialMessage for example.

zenith oracle
#

Iirc it was proposed in a PR times ago but it wasn't possible

#

For example, if Message#content is always string, PartialMessage#content cannot be null as Typescript would error with something like type was reduced to never as types have no overlap

loud jayBOT
ornate topaz
#

There's this, but looks like it was closed due to it already working as a type guard

woeful rain
#

So it wouldn't be a problem to just rename the partial getter to make it an isPartial function

#

Because I think it would be good if the typeguards had the same style.

oak quail
#

bots can set the locale in the headers to get the _localized fields

#

that is documented

outer raven
dawn merlin
#

me and rodry were going back and forth on this, for some reason I can get the fields when I set the locale header, but in his case he doesn't

outer raven
#

My request looked like this, I also removed the query completely later on and still didn’t get them

unknown.png
oak quail
#

it worked when I tried it blobshrug

dawn merlin
#

rodry are you sure you updated your commands with the locales?

#

pretty much doing the same thing as you

Screen_Shot_2022-04-16_at_10.30.40_PM.png
outer raven
#

Yep my commands were translated in that language but I’ll check again tomorrow just in case

copper laurel
#

Your URL is v9

#

Siris is v10

honest barn
#

any chance we can get a builders release soon? there are currently only two open prs for builders and its been a while since the last release

copper laurel
#

dont builders have an automatic dev release build?

solemn oyster
#

You can use dev releases from npm, they contain the latest code in main

copper laurel
#

I'll take that as yes

honest barn
#

i meant a stable release but that works too i guess

#

thanks \👍

outer raven
outer raven
woeful rain
#

Does a major change also count if we change the prefferedLocale type in the Guild structure from string to Locale even though there was previously @see {@link https://discord.com/developers/docs/reference#locales}? I'm asking because I'm doing a https://github.com/discordjs/discord.js/pull/7804 backport for v13 so should I also modify the types in Guild, Interaction or purely just ApplicationCommand which hasn't been released yet.

outer raven
woeful rain
outer raven
#

forgot to undo

honest barn
#

when updating rest to 0.4.0 i get this error which doesnt happen on 0.3.0 npm ERR! code EUNSUPPORTEDPROTOCOL npm ERR! Unsupported URL Type "workspace:": workspace:^looks like crawl forgot to update the package file for collection to 0.6.0

unknown.png
open lintel
#

@opaque vessel is tracking this ⬆️

outer raven
# outer raven forgot to undo

yeah so my antivirus decided that turbo is a virus and keeps deleting it now making it impossible for me to commit, might take a while before I can fix this

#

downgraded to v1.1.4 and it fixed itself, guess I'll have to live with that for now

solemn oyster
honest barn
#

ah okay

uneven blaze
#

Why was discord.js never rewritten in typescript? I thought that was the plan at one point?

solemn oyster
#

It is the plan

#

But we want to rewrite the entire library from the ground up, freeing Discord.js from past bad decision mistakes

ornate topaz
#

it's not exactly a thing that can be done overnight, and renaming all .js files to .ts also does not cut it.

uneven blaze
#

okay thanks for the answer

mighty bough
#

Maybe there should be a way to delete and add roles with the guild member manager
Something like

GuildMemberManager#addRole(memberId, roleId)
GuildMemberManager#removeRole(memberId, roleId)

copper laurel
#

I mean you can do it with GuildMemberManager#edit

mighty bough
copper laurel
#

Yeah, but it can still be done

mighty bough
#

It could be a way so you just need member id, rather than needing the member object

visual hornet
#

it would still need to make 2 requests under the hood

mighty bough
visual hornet
#

you need to make a request to get the current roles, remove or add as necessary, and send the array back

#

that's the format discord accepts

mighty bough
#

You can add/remove 1 role to/from an uncached member though using 1 request

visual hornet
#

not seeing it, only the Modify Guild Member endpoint that takes the full array

mighty bough
copper laurel
#

I mean assuming the current cache is correct its not that hard

visual hornet
#

PUT is a replace, so that would need the full array anyways

#

ah wait, i missed the roleid part
yeah i see that endpoint now
(although it's () not [], and also it'd probably be better to reference the endpoint instead of the property chain that client.api uses lol)

mighty bough
copper laurel
#

whatever info you have on their current roles

mighty bough
visual hornet
#

you can't really index a function (in that sense), that's not how js works
would just be undefined

mighty bough
visual hornet
#

oh interesting, yeah being a proxy that would make sense

mighty bough
#

Do you understand what I'm trying to say? I get it might be a little unclear

copper laurel
#

yes

#

I understand

vernal rose
#

Why discordjs only expands safe builders (adding emoji string, color and all) and not unsafe builders too?

copper laurel
#

Because it's bad enough that we already have three different ways to access builders

The safe builders are the "better" ones that have been included and extended to align with discord.js casing standards

solemn oyster
visual hornet
solemn oyster
#

This is why /rest's router is just better

quiet viper
wild osprey
#

idk if this is the right channel but to make d.js work with deno it will need development so i said it here.

analog oyster
wild osprey
#

o

outer raven
#

did Discord just start enforcing the message content intent?

real jetty
#

I think it's required to pass the intent in ClientOptions in djs v14/api v10

outer raven
#

oh I thought it had just happened, oopsies

vernal rose
# copper laurel Because it's bad enough that we already have three different ways to access buil...

Sorry for late reply. But either u should completely remove unsafe* if don't want peoples to use it. Else you should provide all the features of safe builders to unsafe one too.

Because it's bad enough that we already have three different ways to access builders

You can only export extended djsbuilders and extended djsunsafebuilders bcz they can do the same thing + additional things the builder one does so we only get 2 types of builders.

tacit crypt
#

I mean safe builders are unsafe ones with validation

#

The only reason we have unsafe ones is because some people whined that ohno the object creation was slower due to validation Sadge

vernal rose
vernal rose
quiet viper
#

Offering to many opportunities makes the chance higher for more inconsistency, which can lead later to breaking changes on a new version e.g .setField,

vernal rose
dawn merlin
#

In hindsight, unsafe builders were a mistake imo

#

To clarify, my mistake

golden mortar
#

In hindsight, builders were a mistake because they solved a non-existent problem and created massive amounts of problems

outer raven
#

just delete the package tbh

golden mortar
#

revert to v13 'builders', no one had any issues with them (which I can't say is the same for v14...)

#

I still don't see the problem with "un"safe builders? A person should have more options than "slow down your bot" and "rewrite large portions of your bot to use json"
... and ofc "unsafe" implying that the builders themselves are unsafe to use, not that they are "unsafe" due to having no validation.

tacit crypt
#

They are unsafe in their data, since no validation happens

tacit crypt
#

And if they were, they wouldn't be using JS

#

When I built builders for application commands, the idea was simple. A class that builds api data with validation. You can still see that in slash command builders today.

#

Then we brought in embeds and components, which have deviated from that logic (not necessarily in a bad way but they have deviated nonetheless) and then we had to implement a validation-less variant of those because "very much slower" (valid concern when we were using zod, as it was super slow, not as applicable now with shapeshift)

golden mortar
#

and yet still the only options are "move to a slower system" (still a valid concern, saying it isn't "that" slow isn't a valid reason) or "rewrite large portions of your bot and move to json"

tacit crypt
#

If it were my choice, unsafe builders would disappear entirely. The point of builders is for invalid requests to not reach discord at all (depending on your bot size if you send a lot of invalid embeds and such you'd drain the 10k/10min bucket)

#

I don't understand why you keep tagging yourself on that "slower system" like it affects anyone. It's not that much slower. You will not build that many embeds a second.

#

Benchmarks show that its slower, yes. Does it actually matter in real life? No.

golden mortar
#

Idk why all maintainers only hone in on that one point... the entire builders package was forced in discord.js for a non-existent issue

#

nothing was fundamentally wrong with v13 and how its done there

tacit crypt
#

And who's forcing you to use our builders? We don't use them in the library itself (past the shortcut in .from iirc)..

tacit crypt
golden mortar
#

"use our new builders or rewrite massive portions of ur bot"

real jetty
#

I guess you could technically drag and drop the current unsafe builder class in your project and use that everywhere, so if it gets removed you can still use it

tacit crypt
#

What's realistically stopping you from using the builders?

#

What use case do the new ones break that old ones had

tacit crypt
golden mortar
#

If we're talked about everything, you now need to make a distinction between the two (and yes, this broke a ton of stuff in my bot), having a slowdown for a non-existent problem (still haven't seen the actual problem, only a hypothetical one), the apis being different - ie. you needed to extend them regardless in d.js and ended up duplicating far more code... the fact that you guys recommend using json but push for an arguably worse system than v13 (harder to use, if the problem was new js programmers sending invalid requests, you've just made it 100x harder for them to use the library at all)

#

If there was an actual reason for the change, I have yet to see it. Other than the hypothetical situations or the slight annoyances with typescript of course

tacit crypt
#
  1. What did it break in your bot? Feel free to thread it up
  2. Slowdown, as we've discussed, yes it's a thing, no its not an actual problem
  3. Sure, because the properties of the class are snake_case, the methods are the same
  4. We "recommend" json for those that need raw throughput
  5. Is it harder tho? Previous guides imported MessageEmbed and used the methods, now it's the same (only we provide the class from elsewhere)
  6. Fair enough, there are some annoyances with TS which we ought to fix and we fix them when we're made aware of them/others fix them by contributing
golden mortar
#
  1. Mostly type stuff, but enough subtle changes in my actual code that would make a transition from v13 to v14 next to impossible for js users (probably the majority of people using the lib). Luckily I'm using typescript
    For example not being able to access fields on the non-builder thing, and having to do a weird mixup of toJson to a builder thing, and sometimes the types wouldn't work on that. And then the type was actually an alias for 2 different types which would extend other types, etc (very hard to use)
  2. I would have rather liked to see a push to remove the d.js builders entirely and remove the non-api stuff (hexColor, etc) just to incentivize that, rather than make this mess of builders and non-builders and everything
  3. Not if accessing from a non-builder thing (idk what to call it), and the types really did not like to work with the APIEmbed (etc.). Getting the component stuff to working and having to add these 20 character long type names for generics was just painful (and much harder than v13).
    I remember being able to use ActionRow without a generic, possibly earlier in v14's life or 13.x? It's just painful to use, especially since the ts error isn't the greatest
tacit crypt
#
  1. O.o... if you can find me a repro sample please follow up here or in dms because that doesn't sound right (nor intended)
  2. Alright, that's a fair point, but that's where there's a split between the builders package itself, and the d.js extension of it. D.js is meant to be user friendly, so shortcuts like hexColor exist there, whereas builders are meant to be just basic (validated) take data in make api payload out. Could see why that distinction might not make much sense
  3. You mean MessageEmbed in d.js (or is it called Embed now) vs EmbedBuilder? Could it have been a -types version mismatch?

ActionRows should work fine without generics... Could probably clean that up soon as well (but I thought the generic was not required..)

golden mortar
#
  1. It's all with component stuff from earleir v14 releases
  2. I meant component stuff, but APIEmbed was the only thing I could think of 😅. One example was taking a component from a message and adding it to a new ActionRow for example... the types are not fun to use.
import { ActionRowBuilder } from '@discordjs/builders';
import { Message } from 'discord.js';

declare const message: Message;

const row = new ActionRowBuilder(message.components.map(c => c.toJSON()));
// Type 'APIActionRowComponent<APIButtonComponent | APISelectMenuComponent>[]' has no properties in common with type 'Partial<APIActionRowComponent<APIActionRowComponentTypes>>'
// WTF does this mean?? So confusing!

even though it's not the correct usage, the typescript error (which you wouldn't even receive in js land) is completely useless. Earlier versions of v14 had easier to use types, and this wasn't as a confusing mess

tacit crypt
#

I mean the error is kinda clear, it has nothing to do with the generics

golden mortar
#

Here's a generics related error in my code

Type 'ActionRowBuilder<AnyComponentBuilder>' is not assignable to type 'ActionRowBuilder<MessageActionRowComponentBuilder>'.
  Type 'AnyComponentBuilder' is not assignable to type 'MessageActionRowComponentBuilder'.
    Type 'TextInputBuilder' is not assignable to type 'MessageActionRowComponentBuilder'.
      Type 'TextInputBuilder' is missing the following properties from type 'ButtonBuilder': setURL, setEmoji, setDisabledts(2322)
#

Adding in MessageActionRowComponentBuilder fixes it

tacit crypt
#

Interesting..

#

I mean it makes sense but interesting nonetheless

#

These sort of issues happen when you want type strictness

#

I guess its a matter of do we go for strictness or ease of use..

wild flax
#

Strictness is kinda important

#

Otherwise you could just use raw js

#

Nothing is stopping you there

#

That will always be an issue with ts

#

People want type safety and strictness but not deal with types to a certain degree

#

Seems like a huge clash of ideologies

golden mortar
#

Yep I'm not saying to loosen type strictness, only that right now it requires some underlying knowledge of the types to use properly (ie. understand that MessageActionRowComponentBuilder is part of the AnyComponentBuilder union). It's not as easy to use as v13, or even previous versions of v14. Especially since the ts errors, in part with the types themselves being confusing, aren't the most amazing.

warped crater
#

realistically the types will always be confusing (if accurate) because of the complexity of those data payloads

#

you do end up with very convoluted generics and deep inheritance on all those interfaces but at the end of the day

only that right now it requires some underlying knowledge of the types to use properly
so long as you understand the type system and are familiar with the data the method takes and what properties it accepts depending on other properties (e.g. the component type), it really shouldn't be all that much of an issue

tacit crypt
#

It won't be as simple as v13 as we bring in strictness. That's a given no matter where its implemented or how.. and I'm sure if you asked there's probably someone in here that can guide you

outer raven
#

I'm sorry to interrupt, this is just a simple question can we backport https://github.com/discordjs/discord.js/pull/7507 into v13 or add back the rule that was removed in a commit in v13 so that we can get the old casing on commits back? Also if so, which one of these options would yall prefer?

zenith oracle
golden mortar
#

Yes we've been over this. It's not realistic for people to rewrite massive portions of their bot to do this.

#

I've been working on my bot since around august 2020, so there is a lot of maintenance going into it just for a v14 upgrade (many thousands of lines already), I can't realistically be expected to remove hundreds of embeds... EmbedBuilders.. UnsafeEmbedBuilders.. and replace with json. It would take days lol

tacit crypt
#

So just keep using the builders as is..

golden mortar
#

I'm addressing his point because I hate that argument ("if you don't like it just simply don't use it")

tacit crypt
#

Backport commitlint rule

zenith oracle
# golden mortar Yes we've been over this. It's not realistic for people to rewrite massive porti...

I see what you mean, since I've already done big rewrites for my bots and that's why I started using raw JSON embeds. It's surely another refactor but... probably the last as I don't think (and hope) djs will drop raw JSON support and if you're lazy you can continue using a Builder, which is surely totally safe with its validation.
I'm not saying Unsafe*s should be removed, just that, as we just said, "If you don't like it, don't use it", there's no much difference at the end...

mighty bough
#

Why don't GuildAuditLogsEntry objects have targetId and userId or executorId properties?

copper laurel
#

Because the API returns full user objects when you fetch audit logs, theres no need to rely on cache getters based on id

mighty bough
copper laurel
#

I mean I guess it could be converted to cache getters
https://github.com/discordjs/discord.js/blob/988a51b7641f8b33cc9387664605ddc02134859d/src/structures/GuildAuditLogs.js#L170 caches all the users returned in the payload when they're fetched
https://github.com/discordjs/discord.js/blob/988a51b7641f8b33cc9387664605ddc02134859d/src/structures/GuildAuditLogs.js#L387 the _add call on this line would return an existing user if one was in cache anyway, which they would be due to the above, same for target

peak zinc
#

like, why would you want to continue using the old object after updating it

unique axle
#

patch cache, return pre-update clone so you can still emit both in before/after events

peak zinc
#

ahh that makes sense ty

#

how about Base#_patch()? this implementation seems kinda useless, why not have this be abstract and throw an error if someone tries to call it?

unknown.png
outer raven
#

it's overwritten by other classes that extend Base, that's an abstract method

#

ig they just dont want that error to be thrown

peak zinc
#

it seems like all the other implementations of this in the library don't return anything, so it seems weird to me that this one does return something

peak zinc
bitter peak
#

I'd think an error would make more sense to have

outer raven
#

why do you care it never reaches that point anyway lol

vernal atlas
#

assuming that every structure should have its own _patch then IMO it should throw an error, not return the data

real jetty
#

what User-Agent a bot uses when making a request to the API? I'm trying to access a resource with Postman and I get Access-Denied

real jetty
#

i mean, when i put my browser's user agent i get denied

#

when i leave it empty it works

slate nacelle
real jetty
#

thanks!

outer raven
#

Can we please revert https://github.com/discordjs/discord.js/pull/7759 ? This PR just sounds authoritarian as it is restricting users to one method of doing things where the other one is perfectly valid and not "confusing" at all unlike the PR originally claimed. One can send rest params and it will work and they can also send an array and it will also work, if anything the confusion is on the jsdocs, not the typings and that can be improved without needing this

copper laurel
#

This was discussed a lot before the PR even went up. We were frequently observing users in support passing arrays since theyre a naturally intuitive container object in Javascript and one that even beginners understand. So for that reason, it was important to support arrays.

As for why we no longer support rest parameters, supporting both forms of input has a performance impact - it becomes necessary to flatten or otherwise unwrap the array, if used, from the rest param argument. We are still looking at options to improve performance in that area though to see if supporting both can be viable

outer raven
#

from the people that say the performance impact that validation has on builders is negligible and then say rest parameters are an issue that sounds quite hypocritical if I'm being honest

#

and honestly this diff from v13 to current v14 just looks ridiculous at this point

- embed.addField("test", "abc")
+ embed.addFields([{ name: "test", value: "abc" }])
copper laurel
#

There's also an argument to be made for an inconsistent interface if it accepts two different forms of input, but I know we've been over that on other topics and will probably disagree on it. Can I ask if/why you have a preference for rest params, or why its important to you to see both supported?

outer raven
#

because 90% of the time I'm adding 1 field to my embed and being forced to put that 1 field in an array is just annoying and to me looks like it would impact performance more than using rest params would. For the situations where I'm adding more than 1 field it's still way more practical to pass the objects consecutively rather than throwing them into an array as that slows down development time by quite a lot (specially for someone using a portuguese keyboard like me where the [] are quite annoying to reach)

copper laurel
#

to me looks like it would impact performance more than using rest params would
Supporting rest params OR an array are exactly equivalent performance wise, since rest params become an array argument anyway. Supporting rest params AND an array is where the performance hit is introduced, since thats where we need to do args.flat() or Array.isArray(args[0]) ? args[0] : args or something.

#

I can't really comment on the portuguese keyboard thing since I don't use one, it doesn't take me any time at all to hit [] really

#

In fact a good IDE will put the ] in for you if you hit [ lol

outer raven
copper laurel
#

Not if we also support arrays

outer raven
copper laurel
#

...args, if receiving an array, is [[arg, arg, arg]] vs [arg, arg, arg] if rest

#

It becomes necessary to flatten, unwrap it, whatever

#

To be clear I have no preference either way on if we support both or not, I'd be fine with the performance hit of doing so. But I was in strong support of it not being only rest params because it was clearly unintuitive for users and yeah, the docs display for it sucked

outer raven
copper laurel
#

Yeah that was the other option I listed

#

Array.isArray(args[0]) ? args[0] : args

#

Which I personally am fine with

inland lotus
#

I believe supporting both array and rest would be a good option, if the issue is with typings/docs it could be easily solved by adding a note or making jsdocs..well better

visual hornet
#

I feel this becomes an issue when multiple arrays are passed, feels like that could lead to some unexpected behaviors
and i feel with accepting only an array, the old singular addField may become requested to avoid having to wrap a single option like rodry mentioned

outer raven
#

multiple arrays would never be passed

#

what

inland lotus
#

what if someone, for some reason, does .addFields([...], [...])

visual hornet
#

oh wait, misread some stuff, disregard that
thought we were having rest and array support and were transitioning to array

copper laurel
#

Yeah passing multiple arrays is just incorrect

inland lotus
#

meh, true

copper laurel
#

Although flat would work for that, we're certainly not extending support to a third set of rest-arrays or some shit

#

Yeah tbh my first response to embed.addFields([{ name: "test", value: "abc" }]) was something like "oh so what" but the more I look at it I kinda get it lol

visual hornet
#

yeah i thought it was going like how setAuthor/setFooter got deprecated

outer raven
outer raven
inland lotus
#

isnt the only issue with supporting both rest and array is docs/typings? or is it performance issues?

copper laurel
#

Theres a small performance hit

visual hornet
#

when addField was removed, addFields was still just the rest parameter of objects, so it was arguably trivial to just wrap it up, but now with the array it just seems like it's a bit much for a single field

inland lotus
copper laurel
#

¯_(ツ)_/¯

inland lotus
#

yeah I dont see an issue with supporting both lol

visual hornet
#

i think if supporting both does happen then it might lead to the thing i mentioned with multiple arrays, since although it's not typed like that, users using javascript unfamiliar with the stuff here might just assume that, arrays are valid, rest is valid, why shouldn't rest of arrays be valid
might just be a moot point though

outer raven
#

I don't understand why anyone would come to that conclusion

inland lotus
#

I mean, at first instinct you would either choose to pass one array or rest, only if you're doing it on purpose would you use a rest of arrays 🤷

outer raven
#

also that already happens in v13 and I've never seen that level of stupidity yet

#

also why can't the users that pass an array simply add "..." to the start of their argument tree?

#

wouldn't that make everyone's life easier?

copper laurel
#

Sure but they can just add [] too

#

Except Portuguese people I learned today, sorry about that 😛

#

As an experienced developer, I agree, ...arr is easy, but it really isn't a well understood concept for most people

outer raven
copper garden
copper laurel
#

back to singular methods? 😄

quiet viper
dawn merlin
#

but imo, yes the argument to add singular methods back would be valid now if we were to stick with arrays only

copper laurel
#

The argument not to use builders at all because you can embed.fields = arr or embed.fields.push(...arr) or embed.fields = embed.fields.concat(arr) or embed.fields = [...embed.fields, ...arr]

#

JSON/JS objects superior, supports both arrays and rest

outer raven
copper laurel
#

I mean... this is an interesting debate imo

dawn merlin
#

bc for rest params it's the same method just with an 's'

copper laurel
#

Because we're not "paying" but people do spend time (and time is money) to maintain it

#

"alternatives" are inconsistency, maintenance overhead, in some cases code duplication

outer raven
#

addField is a method that requires no maintenance after it’s implemented. It’s caused more maintenance overhead to deprecate, change syntax and then remove it than it would’ve to just… leave it alone

inland lotus
#

with all honesty, removing singular methods was uncalled for, it was perfectly fine as-is

outer raven
#

Arrays vs rest is 1 line to support both and it’s over with, you don’t have to change that line ever again and you only need to care about whatever else the function does if anything

copper laurel
#

yeah im fine with supporting rest

outer raven
#

Once again we’re back to creating problems to justify solutions that didn’t need to exist in the first place :/

dawn merlin
#

well the original issue was forcing people to use rest over arrays and not allowing both

copper laurel
#

the solution is not using builders

dawn merlin
#

like so many people were passing arrays in bc they didn't know what rest was and it wasn't expected

inland lotus
#

all these the builder changes would force someone to not use them and just use raw objects lmao

copper laurel
outer raven
inland lotus
#

I have also switched to json instead of builders

copper laurel
#

Builders are good if you want your input validated

#

UnsafeBuilders are, imo, pointless over objects

outer raven
#

No, builders are good for type safety and code organization, I could not give one singular fuck about validation yet I use builders everywhere in my code

copper laurel
#

const embed: APIEmbed = {}

#

typesafe

inland lotus
#

just type it as api embed, yeah

copper laurel
#

We have object types

outer raven
#

In fact builder validation is just stupid, the api validates it for ya

outer raven
copper laurel
#

yes

copper garden
#

The point of client side validation is to avoid 400s responses

inland lotus
#

well, as the developer you should know what types of params you're passing to builders, so is validation really needed in that case?

outer raven
#

And why are those bad?

dawn merlin
copper garden
#

There is a rate limit for requests resulting in a 4XX

visual hornet
outer raven
outer raven
#

And not let it sit there

visual hornet
#

the validation tells you to fix your code
is that not what it means

copper laurel
#

There isnt actually a type for the camelCase djs EmbedBuilder constructor param that I can see

outer raven
#

So do 400s

copper laurel
#

But assuming we made one you could typesafe using that

visual hornet
outer raven
copper laurel
#

Thats not typecasting

outer raven
#

So you still have to fix that asap

analog oyster
outer raven
#

Exactly

visual hornet
#

reactively/proactively with regards to sending the request

copper laurel
#

How is it less safe, TS wont let you assign props to that object incorrectly

outer raven
inland lotus
#

typescript fixes all issues with type safety and all that, purely validation is for runtime validation I believe

copper laurel
#

I havent

outer raven
#

It’s never as bullet proof as a function arg

copper garden
outer raven
#

Again, why does that matter

#

It’s an error you’d have to fix regardless

#

So having validation is the same

copper garden
#

Doesn’t consume global rate limit nor the 4XX limit

analog oyster
#

ik it does, but builder validation isnt being fixed proactively

outer raven
analog oyster
#

because it happens at runtime

copper laurel
#

This argument is getting really off track

outer raven
#

And, if you were following the chat, I said you wouldn’t let those errors accumulate so you’d fix your code before hitting limits

copper laurel
#

You praise the benefits of typesafety in TS but you dont praise the benefits of input validation

dawn merlin
#

idk even know at this point, I'm just over builders in general. Note to future me: don't make builder PRs

copper laurel
#

lol

dawn merlin
#

like im so done with all of that shit

inland lotus
#

remove builders altogether meguFace

outer raven
#

Revert back to v13 djs builders happy

dawn merlin
#

I don't even use builders so idk why I even get passionate talking about them

#

let alone make PRs for them

inland lotus
#

I have started using json when I saw the changes to builders in v14...v13 builders were better imo

visual hornet
outer raven
#

Only if you’re sending thousands of reqs per second lol

#

Either way

visual hornet
#

doesn't seem that unlikely for me for that kind of erroneous code

outer raven
#

It would be much easier to have what we had in v13 where builders organized data nicely, didn’t validate and supported all sorts of input for everyone’s likings

copper laurel
#

✨ objects ✨

inland lotus
#

just use typescript

analog oyster
#

not really the point of this conversation, but allow me to show this

unknown.png
dawn merlin
#

but anyways make builders how you want them to be, I don't want to be involved with something I don't use anymore, it's tiring trying to be involved with them

visual hornet
#

why did we have builders in the first place again? to go with rest?

dawn merlin
#

can't remember tbh

analog oyster
outer raven
bitter peak
copper laurel
outer raven
#

Ahh

analog oyster
copper laurel
#

In the sense that unsafe could have done 98% or 102% that many ops

analog oyster
outer raven
#

Right

inland lotus
#

I will just put what I would want builders to be..

1 - either support both rest and array, or bring back singular methods
2 - stop removing functions that were working perfectly before
3 - and bring back v13 builders

outer raven
#

Ok then ye builders are way worse than I thought wow

copper laurel
outer raven
analog oyster
inland lotus
copper laurel
#

I'll do a PR that brings back the singular method and make it require a length=1 array OMEGAlul

copper garden
#

Unions just create unnecessary complexity in the method just to bring it back to a single type or otherwise handle each case

copper laurel
#

The reason why builders exist is basically:
SlashCommandBuilders existed with input validation (and are good)
/builders now exists over there as a weird little thing with no other builder classes in it
discord.js has a bunch of builder classes in it so we move them to /builders and add the same sorts of validations
Those classes end up fairly different to what people are used to because the standards for builders (e.g. snake_case etc) don't align with discord.js
They have to be reimported back into discord.js to avoid code duplication
They have to be extended in discord.js in order to align with discord.js standards while still trying to minimize code duplications

Interestingly enough, if we fully aligned something like EmbedBuilder with SlashCommandBuilder, the interface would be embed.addField(field => field.setName('foo').setValue('bar'))

inland lotus
#

now if you left builders alone in djs that wouldnt be the case, as you moved them to builders, then moved them back to djs to allow camelcase...why all that hassle?

copper laurel
#

It was essentially a sort of repository design/architectural philosophy decision I guess

#

Not one I'm trying to defend or justify, only explain

inland lotus
#

¯\_(ツ)_/¯

#

just from personal experience, these builders changes werent needed and moved me to use objects instead so... yeah ig these decisions werent so good imo

wild flax
#

If you moved to objects, they were good enough

tacit crypt
#

Like the amount of headaches that builders have caused over something that's meant to help you is getting tiring :p
If you don't care about the benefits of validation or you do validation yourself, use unsafe builders or objects. Otherwise use validated builders

#

Builders are meant to help you not send invalid requests to Discord, which depending on your bot throughput and amount of invalid data sent could outright ban you for at least an hour from doing anything with the api

analog oyster
#

If you don't care about the benefits of validation or you do validation yourself, use unsafe builders or objects
... unless if you want to use the features that were added in the extended builders in djs, if so you'll have to use objects as the "unsafe" builders arent being extended in djs

tacit crypt
#

For the 90% of users that's fine and probably much better than getting some obscure error from discord (which I've seen plenty of people not be able to read)

tacit crypt
#

Which affects only component builders currently

#

(ala customId and the gang)

analog oyster
#

embed setColor accepts hex strings
button setEmoji accepts everything that parseEmoji does

tacit crypt
#

(which is something that should be used very sparingly as it does no validation)

outer raven
#

Wdym it does no validation?

analog oyster
#

values passed in the constructor arent validated

tacit crypt
#

What's the use case for hex strings? It's the same as the number variant, only replacing 0x with a hashtag

analog oyster
#

i dont use builders, i was just pointing out the inconsistency

tacit crypt
#

For setEmoji we can probably add shortcuts/overloads for it but there's no inconsistency as builders are working with raw api data

analog oyster
#

but since its available on the regular EmbedBuilder, i assume there are valid use cases

analog oyster
solemn oyster
#

Unsafe builders are meant to be bare metal, they're to be used only by very advanced/experienced developers who know what they're doing, not by the regular users.

#

And the target public they have doesn't whine about little things such as casing or easily fixable abstractions.

analog oyster
#

👍

tacit crypt
#

Creature comfort shortcuts, like setEmoji accepting a string, not just an object, fit more in djs than builders. At their core builders are meant to work with raw api data in a nicer, chainable way (see application command builders), and also bring in validation so the API limit isn't drained from possibly invalid data sent.

outer raven
tacit crypt
#

API doesn't return hex values for anything

#

The only time it did was for the user accent color and that was shortly after changed to a number

outer raven
#

Not Discord

#

Others

thin obsidian
#

Is it best practice to just use objects instead of the e.g addFields function?

mighty bough
thin obsidian
mighty bough
zenith oracle
# thin obsidian but what's considered best practice

It really depends on you. Some prefer to use JSON objects because they are faster, easier to adapt to new features and comfortable if you want to statically send an embed (so you already have all the properties before); others prefer to use Builders because they allow you to validate all properties before sending the embed and are more convenient for example to add fields or do something else dynamically

golden mortar
#

JSON. nothing about builders is more convenient or easier than a normal object

copper laurel
#

This is not the channel for this discussion, and if the question is for best practices than the tool that provided validation would be the one to recommend, personal biases aside

outer raven
#

So what's the takeaway from yesterdays convo about builders and rest vs arrays / singular methods / whatever the hell we talked about here?

#

can we bring back both rest and arrays and singular methods?

copper laurel
#

I dont think that was the takeaway

#

We could bring back rest or singular methods. If we bring back rest, addFields wont require an array and operates as a single method also

#

If we dont bring back rest, singular methods have a more distinct purpose that isn't being duplicated by another method

wild flax
#

I like the idea where we don’t do either

outer raven
#

You also like the idea of breaking every single thing in the library for the sake of it so why bother right

tacit crypt
#

You're the one using an in dev version of WIP software