Binding support for 'bool' values with InputRadioGroup and InputSelect

[MackinnonBuck]

Binding support for bool values with InputRadioGroup and InputSelect

This PR adds support for bool value bindings with the InputRadioGroup and InputSelect components.

PR Description

Added special-cased bool value conversion logic shared between the InputRadioGroup and InputSelect components to address #34816.

Why this special-cased approach?
A general-purpose approach to binding bool values to attributes might seem appealing at first, but I've determined that this may be infeasible without a huge amount of refactoring. The framework currently assumes that binding a bool value to an attribute means the attribute is conditional (i.e. a boolean attribute - it exists or it doesn't). Among other things, we would have to introduce new mechanisms to decide whether a given attribute is conditional or string-valued in order to implement a generalized solution.

Changing the existing bool converter to also convert string values provides one-way binding (JS->.NET), but as soon as we attempt a .NET->JS update, the bound attribute gets bool-ified again. Changing the formatter to always format to a string won't fix this because the framework relies on the distinction between bool and string values after they've gone through the formatter to determine if the attribute is conditional.

Other thoughts
If we determine that it's too weird to only have this special bool binding behavior for InputRadioGroup and InputSelect, it's probably fine that we don't accept this PR. IMO, it's a bit strange to be using select and radio inputs rather than checkboxes for bool values. But, if the developer really wants to, they could already make it work by binding to a string instead and performing their own conversion, or (more reasonably) by using an enum that accurately represents the choice being made.

Fixes #34816

[pranavkm]

Personally think this is a reasonable change to take. I'll defer to @SteveSandersonMS since he's the one most familiar with BindConverter (outside of you 👍🏽 )

[SteveSandersonMS]

I'm guessing that if the code here was Value="@true" and Value="@false" it would still work the same, would it?

If I'm reading the code here correctly, <InputRadio Value="true" /> will be an InputRadio<string> rather than an InputRadio<bool>. Does it make any difference if the developer makes it into an InputRadio<bool>?

I think it doesn't make any difference because the binding machinery is really on the InputRadioGroup which will be an InputRadioGroup<bool> in both cases.

[MackinnonBuck]

Since Value is a parameter of InputRadio, not an HTML attribute, isn't 'true' interpreted as the value true rather than the string "true"? In other words, I think true and @true are equivalent here (correct me if I misinterpreted your comment).

That said, the <InputSelect> case is a little weird in exactly this regard:

<InputSelect @bind-Value="ignoreTheTypeOfThis">
    <!-- We can set the value attribute to an enum, because the bind formatter properly serializes it -->
    <option value="@SomeEnum.Choice">Choice</option> <!-- Good -->

    <!-- But we can't do this with a bool, because now 'value' is treated as a conditional attribute -->
    <option value="@true">true</option> <!-- Bad! -->

    <!-- So, we have to use a string -->
    <option value="true">true</option> <!-- Good? -->
</InputSelect>

[SteveSandersonMS]

This looks ideal to me!

I agree with your analysis about the value of implementing this in InputSelect and InputRadio specifically rather than changing the much broader landscape of rendering and binding logic to make it work on raw elements. In other words, I agree it seems valuable enough to implement for those components, but not universal enough to warrant changing everything for it.

Thanks!