Current Blazor event handling fails for some CustomElement scenarios

[MarkStega]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am using a CustomElement in Blazor that implements checkbox functionality. The component reports the state of checked/unchecked in an identical fashion as a native <input type="checked"> The determination of a checkbox in RenderingEventForDotNet only works for native input controls.

This has been discussed as early as the late stages of .Net 5 with some suggestions and even an incomplete PR
IsCheckbox based on role and not only for input DOM elements #27030
[Blazor] Cannot bind custom checkbox element's checked value

But here we are at .Net 9 and no relief...

Describe the solution you'd like

I posit that there are always going to be some edge cases where mapping the Value can't get handled with addition of a role or other methodology and that other elements of the event may be required.

I can certainly add my own event listener on the custom element and call back into Blazor with the checked state. This works but I consider it ugly.

Slightly less ugly (but I guess it is in the eye of the beholder) I simply created a custom event that grabs the checked attribute. Again, it works, but still not really elegant.

I propose standard events have two maps, the current simplified map so oninput, onchange, etc. all work as they do now and a second set that returns the complete event. These could be named as ondomchange, ondominput or onnativechange, onnativeinput. There would have to be corresponding types in C# that reflect the TypeScript definitions found in lib.dom.d.ts

The goal is just to make it easier in Blazor to use CustomElements that may not be wrapping a native element.

@SteveSandersonMS

Additional context

No response

[javiercn]

@MarkStega thanks for contacting us.

I propose standard events have two maps, the current simplified map so oninput, onchange, etc. all work as they do now and a second set that returns the complete event. These could be named as ondomchange, ondominput or onnativechange, onnativeinput. There would have to be corresponding types in C# that reflect the TypeScript definitions found in lib.dom.d.ts

It's not clear what you are suggesting, but we would be incredibly wary of adding a second set of events to represent the same/similar concepts. We didn't originally expose all the event details because it is in general not possible to serialize all the information in the event.

We could change the code in JS to detect "role=checkbox" but for custom elements in general, we would expect the developer to define the events. If you need more information from the JS side, custom events is the right way to handle this scenario.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.