SelectButton: inverse unselectable behaviour

[tugcekucukoglu]

No description provided.

[tugcekucukoglu]

Fixed via #3610

[rubjo]

@aguyfromdenmark @tugcekucukoglu

Current (3.26.0) behaviour for unselectable true seems to be that the SelectButton cannot be unselected. Does that make sense to you? :)

[jnoordsij]

I'm utterly confused by this change; isn't the old behavior exactly what you would expect, and the new behavior wrong? Moreover, even if you do think this is correct, reversing the behavior is a major breaking change of behavior on a minor version, which will probably end up in lots of people being confused.

I would suggest rolling back this changeset and introducing a more clearly named prop (e.g. allowEmpty or allowClear) instead, deprecating the old one and removing it in a future major update.

[aguyfromdenmark]

@rubjo Yeah, that makes perfect sense. That is the behaviour I introduced in my pull request #3610 , that @tugcekucukoglu merged on the 9th of March. Before that, @jnoordsij , you were able to completely unselect all options in the SelectButton when setting unselectable to true, which to me, is the oppsite behavior of what I expect when I set unselectable to true.

There is a chance that I am misunderstanding what this thread is about, but it am genuinely confused to as what the ongoing "problem" seems to be.

[jnoordsij]

I think the problem is indeed the mixed interpretation of what unselectable = true means; I would interpret it as "the button allows unselecting", which is exactly what it previously did. I think this behavior also matches the description from the docs: Whether selection can be cleared.. So setting it to true would allow clearing all options, setting it to false would disallow this.

I do agree the reverse interpretation migth be logical in some sense as well; hence my proposal to revert to the previous (documented) state and to use a more clear naming to go forward instead.

[rubjo]

Yeah, support @jnoordsij’s suggestion here.

[aguyfromdenmark]

@jnoordsij That makes sense. It can be read both ways. Now, it's a long time since I made my pull request, so I can't say for sure. But I think the docs might have said something else back then, because I was flabbergasted when I found out that it did the inverse of what I expected. I will always read unselectable = true as "this cannot be be cleared".

So I guess this is something for someone else to decide what to do about,

[rubjo]

I read unselectable=true to «can be unselected». 🙂

[aguyfromdenmark]

I read unselectable=true to «can be unselected». 🙂

And there ya' have it 🤣

[rubjo]

Want to chime in @tugcekucukoglu ?

To unselect something is to clear something. Hence, unselectable === clearable.

[rwparris2]

+1 to @jnoordsij 's suggestion.

Definitely don't reverse the behavior as that would break all existing code using that property.

Deprecate it, replace the naming with something less ambiguous.