InputRadio component with form support

[MackinnonBuck]

Summary:

• Implemented a new InputRadio component with form support.
• Added E2E tests to validate its interactivity with edit context.
• Added tests to verify that InputRadio components interact with InputRadioGroup components as expected.
• Added int and Guid binding support for InputRadio and InputSelect.

Usage example:

<InputRadioGroup Name="optional-name" @bind-value="someBoundValue">
    <InputRadio Name="optional-name" Value="option1">
    <InputRadio Name="optional-name" Value="option2">
</InputRadioGroup>

If Name is omitted, InputRadio components are grouped by their most recent ancestor.

Addresses #5579, #9939 and #19562.

[MackinnonBuck]

Open question: Should we ensure that the type of the value bound to InputRadio is either a string or Enum so that we can be sure it will be formatted correctly?

Edit: I'm going to proceed under the assumption that we should, given InputSelect is implemented this way.

[pranavkm]

Looks great. @dotnet/aspnet-blazor-eng could you have a look please?

[SteveSandersonMS]

This is really great, @MackinnonBuck! Thanks for figuring out so many of the tricky details (e.g., around parsing) here and building it in a clean way.

One suggestion around the API: I wonder if it might be possible to make this even more closely equivalent to <InputSelect>, and with fewer options for developers to get things wrong, by being a bit more restrictive around the usage pattern. Specifically, what if we required <InputRadioGroup>, and then put the bind-Value there? Example:

<InputRadioGroup @bind-Value="mySelection">
    <InputRadio Value="Colors.Red">A warm red</InputRadio>
    <InputRadio Value="Colors.Green">An earthy green</InputRadio>
    <InputRadio Value="Colors.Blue">A corporate blue</InputRadio>
</InputRadioGroup>

With this, you no longer have to repeat @bind-Value="mySelection", nor do you have to understand the difference between @bind-Value and SelectedValue. It makes it pretty much a pure swap-in equivalent replacement for <InputSelect>.

Your scheme around an optional "name" looks like it's sufficient to support even the most unusual UI shapes alongside the requirement to declare a group explicitly, e.g. for this:

Pick one color and one country:

[ ] Red
[x] Japan
[ ] Green
[ ] Yemen
[ ] Blue
[ ] Latvia
[x] Orange

... developers could do:

<InputRadioGroup Name="country" @bind-Value="selectedCountry">
    <InputRadioGroup Name="color" @bind-Value="selectedColor">
        <InputRadio Name="color" Value="red" />
        <InputRadio Name="country" Value="japan" />
        <InputRadio Name="color" Value="green" />
        <InputRadio Name="country" Value="yemen" />
        <InputRadio Name="color" Value="blue" />
        <InputRadio Name="country" Value="latvia" />
        <InputRadio Name="color" Value="orange" />
    </InputRadioGroup>
</InputRadioGroup>

BTW if the nested InputRadioGroup turns out to be tricky, I think it would be fine to either not support that initially (it is an obscure scenario), or I'd be happy to work with you on suggesting a mechanism for implementing it.

[MackinnonBuck]

@SteveSandersonMS Thanks for the great suggestions!

I have made those improvements and added tests for them. I had to introduce InputRadioContext and use it as the cascading value to solve issues with TValue mismatching between InputRadioGroup and its child InputRadio components when Nullable was involved. It also helped with making nested radio groups work, as you described in your last comment. Please let me know if you think this approach is desirable. 😄

[MackinnonBuck]

Is there a particular reason we ever limited what types could be bound when using InputSelect? As I was adding Guid and int support, I noticed my code started to look similar to

aspnetcore/src/Components/Components/src/BindConverter.cs

Line 1267 in fb67100

public static BindFormatter<T> Get<T>()

If I modify InputSelect and InputRadioGroup to use BindConverter.TryConvertTo<T> instead of the existing if/else chain, all existing functionality is preserved, and we get Guid and int binding support for free (I've added tests to verify this). This would resolve #9939 and #19562.

[mrpmorris]

Very good :)

[SteveSandersonMS]

This is totally superb! Thanks for making the updates. I did have one further suggested tweak about where the validation CSS classes should show up - let me know what you think. Hopefully that would be a very small change, but if you think it's not the right design please say so. I'd say this is ready to merge once that last question is resolved. The test cases look great too.

Is there a particular reason we ever limited what types could be bound when using InputSelect?

Not as far as I know. It's quite possible that it's a historical artifact of what order we implemented things in. It's great you've found that BindConverter.TryConvertTo<T> works well here - that seems like a big win!

[SteveSandersonMS]

Brilliant, thanks for the final updates! This is a great feature.

[ehills]

Hi team, i've noticed that it's not possible to add an onchange event listener using InputRadio/InputRadioGroup.
It appears that the 'onchange' slot of the InputRadio essentially gets used up by the magic that links the RadioGroup.
Is there another work around?
i.e. I want to fire a onchange event to update a parent element in the form once a radio button has been selected.

[ghost]

Hi @ehills. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.