InputSelectEnum

[GravlLift]

Summary

A new Blazor form component that automatically lists enum values that an InputSelect can receive.

Motivation and goals

I often find myself writing this same InputSelect code over and over:

<InputSelect @bind-Value="model.SomeEnumVal">
    @foreach(var enumVal in Enum.GetValues<SomeEnumVal>())
    {
        <option value=@enumVal>@enumVal</option>
    }
</InputSelect>

A separate InputSelectEnum<TValue> component that removes this boilerplate could be useful, imo.

// Identical output to above
<InputSelectEnum @bind-Value="model.SomeEnumVal" />

I would write this privately for myself, copying the existing InputSelect code and tweaking it. The only changes from the existing code is a modification of the BuildRenderTree method to generate options instead of displaying child content.

However, certain pieces of the InputSelect code that I'd use as a baseline are internal, such as the InputExtensions.TryParseSelectableValueFromString method and InputBase.FieldIdentifier used for value binding and validation messages, respectively.

In scope

• Generating a blazor select with all possible enum values
• Support for nullable enum as a valid TValue
• Input parameter for changing how enum values are displayed, in the form of Func<TValue, string>. When this parameter is absent, display using System.CompnentModel.DataAnnotations.DisplayAttribute.Name if available, then ToString()

Out of scope

• Filtering specific enum values from the options

Risks / unknowns

If we wish to support nullable enums, then using the generic constraint where TValue : Enum is not a valid path. Therefore, type validity will need to be enforced at runtime.

Examples

An existing example of another developer implementing this component can be found here. That particular implementation may have been using the value binding code from this repo as it existed but it now differs from the code we find in main, and thus results in an inconsistent experience alongside the equivalent InputSelect.

[campersau]

Should [Flags] enums be rendered as <select multiple> ?
Should it support attributes like System.ComponentModel.DataAnnotations.DisplayAttribute to display <option value=@enumVal>@enumDisplayName</option> when no Func<TValue, string> is provided?

[GravlLift]

Should [Flags] enums be rendered as <select multiple> ?

I would think we'd stick to the currently established convention of InputSelect where select multiple is determined by TValue being an array.

aspnetcore/src/Components/Web/src/Forms/InputSelect.cs

Lines 14 to 24 in 6eaba08

	public class InputSelect<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)] TValue> : InputBase<TValue>
	{
	private readonly bool _isMultipleSelect;
	/// <summary>
	/// Constructs an instance of <see cref="InputSelect{TValue}"/>.
	/// </summary>
	public InputSelect()
	{
	_isMultipleSelect = typeof(TValue).IsArray;
	}

Should it support attributes like System.ComponentModel.DataAnnotations.DisplayAttribute to display <option value=@enumVal>@enumDisplayName</option> when no Func<TValue, string> is provided?

That's a good idea, and seems to be consistent with the behavior of Microsoft.AspNetCore.Mvc.Rendering.HtmlHelper.GetEnumSelectList.

[mkArtakMSFT]

Thanks for contacting us.
The proposed solution for such a component that you have above looks great and we would like this to be something application developers to write on their own - or provide such a component to the community. We won't build one into the framework.

[campersau]

@DamianEdwards mentioned something like this here #33950 (comment)

[GravlLift]

@mkArtakMSFT any chance of Microsoft.AspNetCore.Components.Forms.InputExtensions getting moved from internal to public? That being inaccessible to the community really the only reason that I'm proposing building it into the framework at all.

[DamianEdwards]

I personally think these kinds of things should be in the framework by default. Punting to the community every time there's an opportunity to provide clear "customer delight" for very common scenarios is misguided IMO. In this case I'd go further and wouldn't make it a discrete component but rather make InputSelect support it.

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.