Builders discrepancies with DJS

[frozen tusk]

So let’s move all discussion about builders + djs here. Just to reiterate the current issue is that embeds and components are the only things in djs that are presented to the developer as snake_case and also only take snake_case inputs in their constructors. My goal was to make djs classes extend builders to bring back this functionality, while also gaining other abilities back such as being able to use Util.resolveColor in Embed.setColor

[rotund ginkgo]

Instead of setColor supporting strings we should export an enum for it

Much safer for typings, much cleaner

Less messy with resolve and hell

[neon creek]

already exists in the constants

[rotund ginkgo]

Then that problem's solved

[frozen tusk]

Well sure, that was just a minor convenience that came with that, but not the main point

[neon creek]

not much you can about about having snake_case properties in the builders stuff, even if you extend it in djs

unless if you want to duplicate keys

[olive prism]

it's not about removing snake_case from builders

[neon creek]

not what i was saying

[olive prism]

#archive-library-discussion message

[neon creek]

embeds and components are the only things in djs that are presented to the developer as snake_case

i was talking about this, not necessarily removing snake_case from builders

[frozen tusk]

If you extend the classes in djs you can remove them, yeah

[neon creek]

you cannot

not easily or cleanly, anyway

[frozen tusk]

How come?

A simple for loop can remove all snake case properties

[neon creek]

using what, delete?

[rotund ginkgo]

Thats not happening

Not in this lifetime

[neon creek]

and good luck typing that, once typescript comes around

[frozen tusk]

It’s used countless times in djs, why not?

[frozen tusk]

We already had the typings

[rotund ginkgo]

Builders take in data via methods and returns api compatible data as their output. Here's a question - why do you need to use the constructor?

Give an actual usecase for passing data in the constructor

[neon creek]

i meant when the whole codebase becomes ts, typing the removal of certain properties from an extended class

[rotund ginkgo]

And is it really that bad to just type image_url instead of imageURL

[frozen tusk]

Lemme explain this for the 10th time today
Having a plain object for component data makes you lose the ability to use the functions from those classes
Constructing the class with no data param and then using subsequent functions to set the data is illogical as you’re changing the object as soon as you create it, and you also lose some performance compared to simply using an object in the constructor
Although this isn’t done in the guides and whatnot, people do use the constructor and used to have it typed in camelCase. If it’s exported, people will assume its properties are in snake_case because literally everything is, and specially people in JS will have a hard time realizing they have to use snake_case on the constructor. It’s not about being harder to type one or the other, it’s about consistency and user friendliness

[rotund ginkgo]

The argument of calling .setX being illogical instead of passing it in the constructor falls because you do the same thing in both cases
You really don't lose any noticeable performance by doing that and I really cannot stress that enough. Unsafe or safe builders have barely any performance penalty and the benefit of safety (in the case of the safe builder) far outweigh your muh nanoseconds of making millions of embeds a second

Supporting camelCase as a nice benefit is something that I think is being discussed. But hell..you could just convert it in your code if it irks you that badly right now. That's my take on it at least