refactor: allow discord.js builders to accept camelCase

[suneettipirneni]

Please describe the changes this PR makes and why it should be merged:

Closes #7376

Extends builder components in discord.js to allow both camelCase and snake_case inputs.

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating
• This PR changes the library's interface (methods or parameters added)

[imranbarbhuiya]

Why not embed too? also can we get that #equal in embed?

or can we get embedEqual, xComponentEqual in new component file?

[KhafraDev]

I still don't see why this can't be left to the user 🤷

[suneettipirneni]

I still don't see why this can't be left to the user 🤷

We had discussions about this internally, and we decided that this library shouldn't be that low level. We'd prefer to keep idiomatic js field names and have the library take care of the rest. The regular builders without json transformations are still available directly from the builders packages.

[KhafraDev]

However it doesn't make much sense in this case, and leads to a bunch of other discussions about what the library should do. In this sense, snake_case is the only case accepted by Discord, so the data the user provides is the data that Discord receives.

edit: I recall a previous issue elsewhere where kyra noted that js doesn't have a universal style guide, so camelCase vs. snake_case vs PascalCase is up to the user to decide mostly, right? Why are only snake_case & camel case accepted in this pr?

[suneettipirneni]

However it doesn't make much sense in this case, and leads to a bunch of other discussions about what the library should do. In this sense, snake_case is the only case accepted by Discord, so the data the user provides is the data that Discord receives.

I mean almost all of props in the library structures use camelcased naming schemes. Beyond classes a lot of pure json option objects are intentionally camelcased. So it would be inconsistent if message payload data didn't follow suit.

[KhafraDev]

For the library it makes sense, but this is data that is being sent to Discord, which only accepts snake_case.

[suneettipirneni]

For the library it makes sense, but this is data that is being sent to Discord, which only accepts snake_case.

It's sent on behalf of the user by the library. The library the developer never sees any of the actual endpoints like they would if the used a lower level library like /rest for example.

[monbrey]

For the library it makes sense, but this is data that is being sent to Discord, which only accepts snake_case.

The data being sent to Discord is still snake_case, and isn't relevant to the changes being made here.

The standalone builders which exist under the /builders structures also haven't changed. They still only accept snake_case because they were designed to be used with /rest, to send data to Discord.

This PR extends those builder classes within the discord.js package to accept camelCase, which is consistent with the rest of discord.js and idiomatic JavaScript conventions.

up to the user to decide mostly, right

Up to the developer to decide. In this case, the developers of discord.js are free to decide on a convention. It's camelCase

[KhafraDev]

and isn't relevant to the changes being made here.

It's entirely relevant... this change adds another layer of abstraction between the data a dev provides and the data sent to Discord. Not only this, but the behavior of discord.js is no longer uniform with builders with this change, which will definitely lead to confusion.

Up to the developer to decide. In this case, the developers of discord.js are free to decide on a convention. It's camelCase

and yet, both snake_case & camelCase are accepted here 😉. Theoretically, discord.js should only accept camelCase, since it's the convention throughout the rest of the lib, while builders uses snake_case.

[monbrey]

the behavior of discord.js is no longer uniform with builders with this change

It never should have been. discord.js should be consistent with discord.js

discord.js should only accept camelCase

I agree, at least as far as the end user interface goes. But these classes are also used internally, when we receive snake_case data from Discord.

They always accepted both in the first place.

[suneettipirneni]

Why not embed too? also can we get that #equal in embed?

or can we get embedEqual, xComponentEqual in new component file?

Support for embeds has been added, equals() method(s) will probably be added in another PR

[ImRodry]

Your commit was meant to say embeds not modals I imagine but why not this one? It’d be within the scope since we’re extending builders classes

[suneettipirneni]

Your commit was meant to say embeds not modals I imagine but why not this one? It’d be within the scope since we’re extending builders classes

Mainly because the getters PR makes comparisons between components much easier.