refactor(Embed): change addField to match v13

[ImRodry]

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

In order to avoid #7522, this PR makes #addField actually useful by allowing the user to pass each one of the parameters in the field individually, for better code readability and ease of writing this over and over, just like we had in v13. I'm making this PR because, as it sits, this method is useless when compared to #addFields, hence why the proposal to remove it, however, there are many scenarios where we indeed only want to add one field, so this method comes in handy.

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 includes breaking changes (methods removed or renamed, parameters moved or removed)

[almostSouji]

we very explicitly removed this behavior from #addField before, I cannot see this becoming a thing again.

[monbrey]

I'm strongly of the opinion that #7522 is the preferred approach here

I would rather not have two very similarly named methods with significantly different parameter interfaces when the single addFields method can easily support adding one or more fields via a standardised object parameter.

[ImRodry]

we very explicitly removed this behavior from #addField before, I cannot see this becoming a thing again.

You never removed it, you just didn’t add it to the builders version. There was no deprecation warning emitted for v13 like there was with other methods

I'm strongly of the opinion that #7522 is the preferred approach here

I would rather not have two very similarly named methods with significantly different parameter interfaces when the single addFields method can easily support adding one or more fields via a standardised object parameter.

It’s exactly because they’re similarly named that their interfaces should be different. This makes a clear distinction between the two and gives users an actual reason to use this method over the other, whereas right now there is none. I think this would result in a better user experience overall when v14 releases, if you care about that

[monbrey]

I think this would result in a better user experience overall when v14 releases, if you care about that

Of course I care, I simply don't agree that this is the better experience.
Changing the way a useless method accepts the same properties it already accepts is not what I would consider adding use.

It would also be inconsistent to other addThing methods of other builders, which (arguably) should also be dropped, since they clearly can't be switched across to something like addComponent(label, type, style, placeholder, etc)

[almostSouji]

You never removed it, you just didn’t add it to the builders version.

I do not understand how not continuing something in a replacement is not equal to removing it.
As monbrey has said above (and I said in the linked thread): semantically, #addFields is the more sensible one to continue.
Doing things in different ways with differing syntax introduces confusion and inconsistency.

[ImRodry]

You can’t apply the logic used here to components. Embed fields have a visual order on the app: the name comes first, then the value, which is why it makes sense to have the name be accepted first and then the value on this method, followed by the inline boolean as that is an optional parameter. It wouldn’t make sense to spread a button in this way because its props are not visually ordered.
Also when I say this is adding use to the method, I mean it’s adding a useful difference to the other one because at the moment you can seamlessly switch between the two methods and see the same behavior, which makes addField obsolete. If this doesn’t go through then I absolutely agree it should be removed, I’m just saying it should stay because you know many people like to use this method and now that TypeScript and VSCode added support for named parameters in the editor, it becomes even easier to use it

[ImRodry]

You never removed it, you just didn’t add it to the builders version.

I do not understand how not continuing something in a replacement is not equal to removing it. As monbrey has said above (and I said in the linked thread): semantically, #addFields is the more sensible one to continue. Doing things in different ways with differing syntax introduces confusion and inconsistency.

There is no inconsistency when there’s nothing to be consistent with. You cannot compare this method with any other on the library, so there’s no “rule” for it to follow

[almostSouji]

.addFields({name: "foo", value: "bar"})
.addField("foo", "bar")

two methods, different usage, achieve the same thing.
yes there is an inconsistency here

[monbrey]

.addFields({name: "foo", value: "bar"}) .addField("foo", "bar")

two methods, different usage, achieve the same thing. yes there is an inconsistency here

Likewise

.addField("foo", bar")
.addComponent({ type: 2, label: "foo", style: 1 })

Because as you said yourself

You can’t apply the logic used here to components

I agree, which is why I consider applying it here an inconsistency we don't need when addFields meets requirements already.

[ImRodry]

That “inconsistency” is good here because otherwise why would you even use addField in the first place?
To put it very simply: curly brackets are annoying to type on a lot of keyboards, just like colons are, and if someone wants one and only one field to be added they could spare the hassle of having to type them to just lay out a simple field. This is the user experience I’m talking about, but you probably don’t have this issue on english keyboards

[almostSouji]

why would you even use addField in the first place?

Exactly, which is why I think it should be removed. It's obsolete against #addFields and giving it inconsistent usage with how the multi-version of the method works introduces confusion in end users.
Yes, that is part of UX design - consistency

[kyranet]

Closing this PR, it seems forced to bring more heat to a change the development team decided to take. As such, we will not proceed with this PR.

@almostSouji's and @monbrey's points are very valid.