Support multiple event handlers for the same event on the same element

[SteveSandersonMS]

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?
• 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.

[rynowak]

a single @onsomeevent that calls a code-genned method that runs all the handlers.

Let's be careful when we get here - this kind of solution will be really tricky because we don't want to influence evaluation order.

[SteveSandersonMS]

Agreed it's tricky.

One especially difficult bit, that might even be fatally difficult to most designs, is making this work alongside our existing AddMultipleAttributes-overriding logic. Currently we reason that, since you can only finish with one attribute with a given name, we can have a precedence rule whereby later instances overwrite earlier ones. It's unclear how this makes sense in a world where you're allowed to finish with multiple instances of a given attribute - how do we know when to overwrite, and when to duplicate?

Maybe the distinction is just "event handlers combine, other things overwrite" but I'm not confident that's desirable without a lot more careful consideration.

[orthoxerox]

I've ran into this with my toy application: three sliders that are bound to three properties and must recalculate a few output properties on change. The most concise way would be to @bind the sliders to the properties and handle @onchange with Recalculate().

This means that @bind must come first in the combined event handler, but I wonder if anyone has the opposite requirement.

[mrlife]

It's unclear how this makes sense in a world where you're allowed to finish with multiple instances of a given attribute - how do we know when to overwrite, and when to duplicate?

Maybe the distinction is just "event handlers combine, other things overwrite" but I'm not confident that's desirable without a lot more careful consideration.

@SteveSandersonMS For event handlers, you could add -callback or similar to the event handler name, e.g. onchange-callback to indicate "run this after the built-in onchange event handler".

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[szalapski]

I would very much like to see this worked on. I have in many components implemented an EventCallback parameter such as ValueChanged, upon which I always implement another parameter EventCallback ValueChanged2. The first is to support @bind-Value, the second to support actual custom events. In every case, I have some kind of private Task ValueChangedInternal() method that always does the internal change work, then calls await ValueChanged.InvokeAsync(Value); then await ValueChanged.InvokeAsync(Value);. I figured I cannot run ValueChanged2 before I await ValueChanged, as the result of ValueChanged (for @bind-value) might be required in whatever event is wired up to ValueChanged2.

If you could support @bind-Value with also having a custom ValueChanged unrelated to the binding, that would clean this up a lot. I would not expect it to be super-deluxe foolproof, just to finish the @Bind function (which should always be quite fast, right?) and then start the custom ValueChanged function.

[SteveSandersonMS]

Note that #39837 supersedes this requirement. That might seem different, but it's a proposal to enhance @bind in some ways that, if done, would entirely cover the realistic use cases expressed here.

[mkArtakMSFT]

Closing as this is being superseded by #39837 which we've decided to move forward with.