Cannot bind custom checkbox element's checked value.
I am using the new FAST web components in a Blazor server side application and trying to bind the checkbox component any way I can, referencing <input type="checkbox" />:
<!-- Works! -->
<input type="checkbox" @bind="MyBool" />
<!-- Does not work... -->
<fast-checkbox @bind-checked="MyBool" @bind-checked:event="onchange"></fast-checkbox>
<fast-checkbox checked="@MyBool" @onchange="@((ChangeEventArgs e) => ViewModel.AcceptTerms = (bool)e.Value"></fast-checkbox>
I know the values themselves are binding because changing the native input will cause the fast components to change to match. The problem seems to lie within the event. The event mapping code has a check built in specifically for checkboxes which causes the change event value to fall back to element.value, in this case e.Value is always "on".
Rather than making an exception for checkboxes, could we simply always include both value and checked in ChangeEventArgs to match the JavaScript behavior? If this approach is acceptable I will open a PR.
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.
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.
I just had a similar problem
@* Works *@
<input @bind="@Value">
@* Nope! *@
<fluent-text-field @bind="@Value"></fluent-text-field>
The value is: @Value
It seems Blazor's @bind attribute can not listen to the events dynamically.
It is a major problem, as it causes incompatibility with custom elements e.g. the new fluent's web components do not work in Blazor properly.
@arshia11d for custom elements you need to specific an event. Try:
<fluent-text-field @bind-value="Value" @bind-value:event="onchange"></fluent-text-field>
@CuddleBunny Thanks
Yes, the event mapping must be explicit for custom elements, and it works just fine.
I just found out what my problem was. It seems that changing value attribute is not mapped to the value property of the fluent-text-field component.
In Web Components, it is common to map public primitive properties like value to an HTML-attribute by setting a static attributes getter in the component class and listen to those changes using attributeChangedCallback to update the property, which FAST and Fluent web components don't support(?) for some reason.
So in my case Blazor actually did set the HTML attribute value but the web component didn't react to it, which causes the data-binding to work one-way, which was unexpected for me.
Could it be the same thing for you with the checked attribute?
@arshia11d - two-way works for my checkbox. If I bind a native checkbox input to the same value they will both update to match. Blazor just doesn't properly populate ChangeEventArgs because it only does so if the target is input type="checked": https://github.com/dotnet/aspnetcore/blob/1455aaeff118aeaf2b0ab5f1627c2c8ca5df7f11/src/Components/Web.JS/src/Rendering/EventForDotNet.ts#L218-L220
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.
Can be fixed quite easily if we add the role="checkbox" since Fast sets the role.
Would this be acceptable?
return (!!element && element.tagName === 'INPUT' && element.getAttribute('type') === 'checkbox'))
|| !!element && element.getAttribute('role') === 'checkbox' ;
@vertonghenb - that's a good idea. Though I think Blazor should support any scenario that the vanilla web would. It wouldn't be unfair to require that developers of custom elements set a role though, since that's best practice anyways.