[LionSelectRich] form event not dispatched

[MatthieuLebigre]

Expected behavior

When I select an option from a LionSelectRich component, I expect it to dispatch the select event, and/or the lion user-input-changed event

Actual Behavior

When I select an option from a LionSelectRich component, no event is dispatched

See https://studio.webcomponents.dev/edit/RWQMWWVDU73unFNft6NP/src/index.js?p=README.md

Additional context

@lion/ui: "0.2.0",

[DannyMoerkerke]

The only event that is currently dispatched is model-value-changed.

[tlouisse]

@MatthieuLebigre would it also be possible to do for now:

<lion-select-rich @model-value-changed="${({detail}) => {
  if(detail.isTriggeredByUser) {
    // do my thing
  }
}}">
...
<lion-select-rich>

See: https://lion-web.netlify.app/fundamentals/systems/form/model-value/#event-meta

Why?

user-input-changed was meant to internally normalize interaction element / ._inputNode events inside FormatMixin...¹
To explain the need for normalization a little better:

• input/textarea fire input event on keystroke
• select fire change event on keystroke²
• my-custom-interaction-element fires my-custom-change event

FormatMixin should only be bothered with one (protected) event, w/o knowing implementation details of _inputNode.
It's up to a Subclasser creating a LionField extension to normalize an event.

Hindsight wisdom: _normalized-input-node-changed would have caused less confusion as a name 😅

For future discussion...

I would be really happy to see if we can improve our apis.
The outcome might be that we agree to use user-input-changed everywhere as a public event :)
Then we would need to apply this in a consistent way throughout the whole codebase.
But maybe we want to align more with the platform as we integrate Form Participation/ElementInternals in the future and we go for just a change or input event. Also see: #24
Really happy to hear your suggestions here as well! 🙂

Footnotes

1. We should have better documented this (we need api tables and better docs), but
   user-input-changed is meant as a 'protected api': ↩

2. In the past, select used to only fire change on IE, but input on chromium ↩

[MatthieuLebigre]

Hello!
Ok I see. I misunderstood the documentation. I though user-input-changed was already this normalized event, part of the public API. The name is indeed misleading :D

For the time being, using the model-value-changed event could indeed be enough. My initial need was to be able to listen to any change of a form, and then apply extra validations. Having a more normlized event like the native change or input would be nice in my opinion. However if the model-value-changed event could be used for this same purpose, maybe it would be too redundant to have another event...
I haven't played enough yet with advanced form validation to see with the model-value-changed would enough in all circumstances.

So my thoughts:

• Rename the existing event user-input-changed to something more abvious it's an internal event
• Update documentation
• Evaluate if model-value-changed is enough for now
• For the future, probably align with https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals