[Blazor] API proposal for InputHidden

[javiercn]

Background and Motivation

Currently, Blazor developers using SSR (Server-Side Rendering) and EditForm need to use raw HTML to create hidden input fields:

<input type="hidden" name="model.Id" @bind-value="model.Id" />

This approach is inconsistent with other Blazor input components that have dedicated wrappers (InputText, InputSelect, etc.). The lack of an InputHidden component creates an odd gap in the framework's form input components, making model binding more complex than necessary.

Adding an InputHidden component will provide a consistent API surface for all form inputs and simplify model binding scenarios in Blazor applications.

Proposed API

namespace Microsoft.AspNetCore.Components.Forms
{
+    public class InputHidden : InputBase<string?>
+    {
+        public ElementReference? Element { get; protected set; }
+        protected override void BuildRenderTree(RenderTreeBuilder builder);
+        protected override bool TryParseValueFromString(string? value, out string? result, out string? validationErrorMessage);
+    }
}

Usage Examples

// Simple usage in an EditForm
<EditForm Model="@model" OnValidSubmit="@HandleSubmit">
    <InputHidden @bind-Value="model.Id" />
    <InputText @bind-Value="model.Name" />
    <button type="submit">Submit</button>
</EditForm>

// With additional attributes
<EditForm Model="@model">
    <InputHidden id="user-id" @bind-Value="model.UserId" />
    <InputHidden @bind-Value="model.SessionToken" class="security-token" />
</EditForm>

// Accessing the element reference
@code {
    private InputHidden hiddenInput;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender && hiddenInput.Element.HasValue)
        {
            // Can interact with the element if needed
            var elementRef = hiddenInput.Element.Value;
        }
    }
}

Alternative Designs

The proposed design follows the established pattern of other input components in the framework, inheriting from InputBase<T> and providing a consistent API surface.

Risks

N/A

[dotnet-policy-service]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[javiercn]

No changes here

[halter73]

API Review Notes:

• We considered making it generic so we could autmatically cache ToString() calls avoid allocations when repeatedly render the form. In the end, we decided it wasn't worth the effort given you could cache manually.