Question / Discussion: Break all native input and change events?

[koffeinfrei]

As recently done in #1065 the native input and change events were replaced by custom events. In one of our codebases we heavily rely on the native events. This breaking change requires a major refactoring. We also have cases where we need some information from the native event, which is not possible anymore.

1. What is the reasoning behind these changes?
2. Could an alternative be to leave the native events in place, and use other custom events additionally?
3. Going forward can we expect for more native events to go away? I.e. should we stop relying on native events support altogether?

You mentioned in #977 (comment) to favor the custom events over native events. That's fair enough as a best practice, but I didn't expect you to drop them altogether 😅. I believe that native events should still be available. Carbon react supports the native events too (i.e. exposes the native event properties).

[metonym]

What are your use cases? Do you use the native event to manually control state? Do you need to prevent the default behavior?

[koffeinfrei]

The main use case is to keep track of the changes in a model data structure. For this we use the name and value from the event.target to update the data on change. The new events only provide the value, which requires us to refactor our components to include the name in another way.

Because of the current inconsistency it's unclear which events are forwarded and which are dispatched without looking at the documentation. Relying on the name alone doesn't tell if the event is native or not.
Is the ultimate goal to be consistent in not forwarding native events?

[theetrain]

While thinking about standardizing events (see #1621), I thought about your comments and came up with this demo:

https://svelte.dev/repl/9b1e3a7822bb4aac9418c95f518523e7?version=3.55.1

• forward native events
• dispatch custom events that are always named differently from native events

The demo above showcases how Pagination would forward events with multiple underlying <select> elements.

• When the user makes a change to a <select>, you can have an on:change handler in Pagination listen for the native change event for that respective <select>, and make a determination based on e.target.name and e.target.value.
• You can also listen to a custom event on:change:page and make a determination based on e.detail containing an object {page: value}

Let us know if this sounds favourable or if there are potential improvements or conflicts to cover.