Closed
Description
Currently, Blazor only allows a single onsomething
for a given element. A consequence of this is that:
- if you're using
@bind
you can't also use@onchange
(because the framework is using it) - if you're using
@bind:event="oninput"
you can't also use@oninput
(because the framework is using it)
This is a limitation we should be able to relax, and would help fix issues like #14242 (comment)
Ways we could fix it:
- At compile-time, by making the Razor compiler able to detect duplicate
@onsomeevent
(including ones it creates itself via@bind
) and collapse them into a single@onsomeevent
that calls a code-genned method that runs all the handlers.- Some design would be needed to decide on execution order. Do we run them in parallel, or sequentially? Do we inject
StateHasChanged
calls that run after each of the returned tasks complete, so as to preserve the usual updating behavior?
- Some design would be needed to decide on execution order. Do we run them in parallel, or sequentially? Do we inject
- At runtime, by changing the diff algorithm to be able to handle multiple values for a given-named attribute. It might be tricky to do this while preserving current perf characteristics, but I haven't attempted yet.
- We'd also need the ts-side code to understand that, when a certain DOM event occurs, it might need to trigger multiple event handlers. If it currently stores the eventname->handler_id mappings as a dictionary keyed by eventname, it would have to be generalised.
Metadata
Metadata
Assignees
Labels
This issue tracks a big effort which can span multiple issuesThis issue requires design work before implementating.Work that is critical for the release, but we could probably ship withoutThis issue impacts approximately half of our customersIncludes: Blazor, Razor ComponentsThis issue represents an ask for new feature or an enhancement to an existing oneAny feature that affects the component model for Blazor (Parameters, Rendering, Lifecycle, etc)This label is used by an internal tool