[select-rich] Implement @change event

[MathieuPuech]

There is currently only @model-value-changed event on the select-rich component. I would like to have a @change event with the same behavior of native select change event.

[MathieuPuech]

I can create a PR if you agree with that

[MathieuPuech]

I think we may not use change for the event name since it's not a trusted event. What should be the name of this event?

[jorenbroekema]

Hmm I think in general you should use @model-value-changed instead of @changed. The reason why you can use @changed sometimes is probably because that custom input wraps a native input, which is not the case for a rich select. We could dispatch it ourselves, but I'm not sure what the added value would be over @model-value-changed, they would essentially be synonymous if we did this right?

[MathieuPuech]

You're right, I've just tested on Mac, it's better for the model-value-changed. The only thing is there is 2 model-value-changed fired on load (mac safari). I don't know why there is 2 fired (that's another issue).

I didn't remember there was another issue related to the model-value-changed fired too much on windows:

#708

[jorenbroekema]

Soo yeah I get the same as Thijs on 708, so if I understand correctly, we need to solve #708 and create another issue for initial model value changed fired twice on Safari, and then this discussion can be closed? Or is there something else?

We will soon have cross browser tests enabled in our CI, so then we should be able to create a failing test + issue for the initial model-value-changed fired twice on mac safari. Will let you know!

[daKmoR]

jup there is already a failing test for the model value if we run it on webkit 😅

#1021

[MathieuPuech]

Yes #708, another issue for safari but there is the initial event sent on all browsers that is maybe another issue too

[tlouisse]

@MathieuPuech @jorenbroekema @daKmoR Sorry for the very late response.
A simple way to solve #708 would be to suppress firing model-value-changed until the dropdown closes and fire an extra event on dropdown close.
But then we would have a situation where mySelect.modelValue would not be in sync.

Making modelValue not update for ChoiceGroups when opened would have quite a big impact on code, I think. And it would be breaking for people depending on this api (getting feedback about the fact that a user changed a value might be handy sometimes (on top, there is no way to 'cancel' the selection, which pledges for the case of getting this info as soon as possible)).
We would also have different behavior for a listbox and a dropdown listbox (or do we want to have the same behavior on blur of a listbox? And what about radio-groups/checkbox-groups?)

What we could also do is add meta info in the model-value-changed event, like we do for isTriggeredByUser as well: #1167

So smth like:

<lion-select @model-value-changed="${myHandler}">

function myHandler(ev) {
  if (!ev.detail.isChoiceInProgress) {
     // select changed
  }
}

There are probably better names for this :)

[jorenbroekema]

I think I'm moving this to discussion since it's not a bug but more a discussion or feature request