-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Closed
Labels
Components Big RockThis issue tracks a big effort which can span multiple issuesThis issue tracks a big effort which can span multiple issuesNeeds: DesignThis issue requires design work before implementating.This issue requires design work before implementating.Priority:1Work that is critical for the release, but we could probably ship withoutWork that is critical for the release, but we could probably ship withoutaffected-mediumThis issue impacts approximately half of our customersThis issue impacts approximately half of our customersarea-blazorIncludes: Blazor, Razor ComponentsIncludes: Blazor, Razor ComponentsenhancementThis issue represents an ask for new feature or an enhancement to an existing oneThis issue represents an ask for new feature or an enhancement to an existing onefeature-blazor-component-modelAny feature that affects the component model for Blazor (Parameters, Rendering, Lifecycle, etc)Any feature that affects the component model for Blazor (Parameters, Rendering, Lifecycle, etc)severity-majorThis label is used by an internal toolThis label is used by an internal tool
Milestone
Description
Currently, Blazor only allows a single onsomething for a given element. A consequence of this is that:
- if you're using
@bindyou 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@onsomeeventthat 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
StateHasChangedcalls 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.
StevenRasmussen, amdav, vicinity-brenon, aayjaychan, AmarjeetBanwait and 7 moremrlife, boukenka, amdav, JohnKiller and RyoukoKonpaku
Metadata
Metadata
Assignees
Labels
Components Big RockThis issue tracks a big effort which can span multiple issuesThis issue tracks a big effort which can span multiple issuesNeeds: DesignThis issue requires design work before implementating.This issue requires design work before implementating.Priority:1Work that is critical for the release, but we could probably ship withoutWork that is critical for the release, but we could probably ship withoutaffected-mediumThis issue impacts approximately half of our customersThis issue impacts approximately half of our customersarea-blazorIncludes: Blazor, Razor ComponentsIncludes: Blazor, Razor ComponentsenhancementThis issue represents an ask for new feature or an enhancement to an existing oneThis issue represents an ask for new feature or an enhancement to an existing onefeature-blazor-component-modelAny feature that affects the component model for Blazor (Parameters, Rendering, Lifecycle, etc)Any feature that affects the component model for Blazor (Parameters, Rendering, Lifecycle, etc)severity-majorThis label is used by an internal toolThis label is used by an internal tool