Details of bundle changes (experimental)

Generated by 🚫 dangerJS against 9089962

@eps1lon This sounds about right. The types are the same. In #23708 we talk about separating them. IMHO, the main value of the isOptionEqualToValue's name is to highlight that use case. The method is always used to compare one selected value with one option.

The nominal use case for the prop we are discussing is when the value and options props are fetched from the database into two different requests. They have a different JS reference but the same type (type might change with #23708),

I don't follow the implementation detail aspect. This comparison prop only exists because there are two different props: value and options. For comparing two options from options, using the reference is enough.

areOptionsEqual is a better name that isn't tied to the current implementation.

We're not comparing options with options. This function compares an option with the selected value (or values, if multiple).

So I guess this is a matter of angle we pick to look at the problem.

• If we consider it from a type perspective, then areOptionsEqual is more accurate.
• If we consider the core of the problem solved by the prop, then isOptionEqualToValue is less confusing.

I would vote for giving less weight to the type in this very instance as we have indicators in #23708 that sharing the same type might not be ideal.

May I push forward this one? I feel we didn't come to an agreement about the name: areOptionsEqual or isOptionEqualToValue.

@m4theushw What's your preference on the naming Y?

Looking a bit closer at #23708. If we implement a getOptionValue prop like react-select has, then it will impact the behavior of Y. Effectively, we will then be able to use getOptionValue to remove the need for developers to implement Y, as we would be able to use getOptionValue most of the time, returning a plain string|number we can strictly compare (===). If we do such, it reinforces the idea that the semantic of isOptionEqualValue is less confusing for Y but also makes the prop less important (no need for using it in the demos anymore).

In https://select2.org/getting-started/basic-usage, it's actually simpler, they force you to have the equivalent of getOptionValue, so there is no concepts of Y.

Just looking on what we have now, I would rename to isOptionEqualToValue. Although the argument types are the same, the value may not have the same shape of option in an application, so it's good to make a distinction between the option and the value.

If we implement the getOptionValue prop, the isOptionEqualToValue prop will be less important. I can think in only one situation where it's needed, which is when the value is an object and the options change over time (e.g. async loaded options). We have only one demo using it and I think we should keep it.

Just looking on what we have now, I would rename to isOptionEqualToValue

Ok, let's move forward with this then.