InputText component should provide a FocusAsync() method

[meziantou]

The PR #23316 introduced ElementReference.FocusAsync() which is convenient to focus an html element.
In my case I need to focus an <InputText> component in a form. There are 2 cases where I want to focus the element:

• In OnAfterRenderAsync when firstRender is true (similar to autofocus)
• On form submit to focus the element when the user doesn't provide a value

I currently use a custom component that inherits from InputText and provide a FocusAsync method.

@inherits InputText
@inject IJSRuntime JSRuntime

<input @ref="inputElement"
       @attributes="AdditionalAttributes"
       class="@CssClass"
       value="@CurrentValue"
       @oninput="EventCallback.Factory.CreateBinder<string>(this, __value => CurrentValueAsString = __value, CurrentValueAsString)" />

@code {
    private ElementReference inputElement;

    public ValueTask FocusAsync()
    {
        // could be replaced with inputElement.FocusAsync() with the next release
        return JSRuntime.InvokeVoidAsync("BlazorFocus", inputElement);
    }
}

In the parent component I can use FocusAsync when needed which works well.

I think InputBase<T> or each component should have a FocusAsync method, so I don't need to override components:

namespace Microsoft.AspNetCore.Components.Forms
{
    public class InputBase<T>
    {
+        public ValueTask FocusAsync();
    }
}

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.

[meziantou]

My issue is about doing the same for the <InputXXX> components such as <InputText> or <InputNumber>. How do you focus the <input> element produced by the <InputText> component in the following example:

<EditForm Model="@exampleModel">
    <InputText id="name" @bind-Value="exampleModel.Name" /> @* How to focus this component *@
    <button type="submit">Submit</button>
</EditForm>

@code {
    private ExampleModel exampleModel = new ExampleModel();
}

I don't think ElementReference.FocusAsync is of any help here. That's why I'm suggesting adding a FocusAsync method to the InputBase<T> class.

[uabarahona]

Yes, I have misunderstood the issue and rushed the answer 😃

I would like to work on this so I will check again and will back with a proposal

[zHaytam]

Doesn't this mean that all InputX components will have an ElementReference by default?

[meziantou]

Indeed, you need to add an ElementReference somewhere. The hard part is making it inheritance friendly. Indeed the child component can override the RenderTreeAsync method so the expected ElementReference is not set and the FocusAsync method doesn't work anymore. I'm not sure there is a way to enforce the child class to set the ElementReference or override the FocusAsync method.

[uabarahona]

Yes @zHaytam, altrought I don't think the ElementReference need to be public but we need that to implement it, here is my proposal:

Starting with a very straightforward approach we could make the following changes

• Change the inputBase like this:

public abstract class InputBase<TValue> : ComponentBase, IDisposable
{
    ----
    protected ElementReference? BaseElementReference { get; set; } = default!;

    ----
    public ValueTask FocusAsync() => BaseElementReference?.FocusAsync() ?? default;
}

• Add a code like below to each child

protected override void BuildRenderTree(RenderTreeBuilder builder)
{
    ----
    builder.AddElementReferenceCapture(5, __elementReference => BaseElementReference = __elementReference);
    ----
}

⚠ Note: Unfortunately InputRadio is not a InputBase so we will need to reproduce this logic only for that component

Looking forward

I have noticed a bunch of calls are duplicated on each Input component

builder.AddMultipleAttributes(1, AdditionalAttributes);
builder.AddAttribute(2, "class", CssClass);

and now the new addition will too

builder.AddElementReferenceCapture(5, __elementReference => BaseElementReference = __elementReference);

Not sure what you think but we can have a method on InputBase that receives the current sequence , do the common calls for the builder and finally return nextSequence. I thought this can be a method on InputExtensions but some attributes are not public so it will not work there.

@javiercn @mkArtakMSFT Please when you have time let me know what you think about the proposal and if you are agree I can continue with the implementation.

[uabarahona]

@meziantou and for inheritance I believe you will need to do this:

@inherits InputText

<input @attributes="AdditionalAttributes"
       class="@CssClass"
       value="@CurrentValue"
       @ref="@BaseElementReference"
       @oninput="EventCallback.Factory.CreateBinder<string>(
         this, __value => CurrentValueAsString = __value,
         CurrentValueAsString)" />

Where @ref="@BaseElementReference" is the key, that way FocusAsync can continue working

[pablopioli]

IF there were an additional level in the "form helpers" like InputText

InputBase --> FormInputs --> InputText

I would implement this in the theoretical class FormInputs, as they are abstractions to build things fasts. If you are overriding InputBase you could be doing a lot of different things.

But, as this additional level does not exists I believe the proposed solution is a good trade off.

[MackinnonBuck]

I like the proposal @barahonajm is suggesting. A few thoughts:

• We should be careful about dynamically assigning sequence numbers (see https://gist.github.com/SteveSandersonMS/ec232992c2446ab9a0059dd0fbc5d0c3). I would suggest that either the common RenderTreeBuilder calls should be wrapped in OpenRegion/CloseRegion to avoid passing around a nextSequence, or the calls shouldn't be abstracted out at all.
• Just an idea, but should we consider making BaseElementReference itself publicly accessible and not explicitly adding FocusAsync to InputBase? That way, if more ElementReference helper methods like FocusAsync are added in the future, we would get those for free in edit form components without having to expand the public API surface. It would also allow users to write their own JS influencing input elements wrapped by an InputBase component.

[uabarahona]

Thanks for your answers @MackinnonBuck @pablopioli !, I will look at sequence number more deeply.

The reasons behind having BaseElementReference public sounds promising indeed it may solve the conflict I was having, see, from what I saw the Focus() is not function limited to inputs it can be used everywhere so, does it make sense to have BaseElementReference public into the ComponentBase? and then let the user somehow define their BaseElementReference so they can have access to all these helper methods like FocusAsync

• Of course, for some components like the Input ones we can set BaseElementReference by default
• This will allow RadioInput to inherit the behavior without repeating code

[MackinnonBuck]

@barahonajm I acknowledge the advantages of moving BaseElementReference to ComponentBase as you've outlined, but I would argue that it doesn't belong there for a couple reasons:

• That's a huge API change for this (relatively small) feature. Every .razor component inherits from ComponentBase, so all existing components would now implicitly get this new BaseElementReference property, which we will be required to support forever.
• I would argue that it's fairly rare for Blazor components to simply wrap a single HTML element as most InputBase derivatives do. For any other case (e.g. pages, layouts, components that render zero HTML elements, etc.), BaseElementReference does not apply.

Something else to consider - InputRadioGroup derives from InputBase, but it doesn't actually render any HTML elements explicitly, so BaseElementReference doesn't even make sense in that context. There are a few ideas that come to my head about how to handle this (in no particular order):

1. Make BaseElementReference an abstract property and have InputRadioGroup throw a meaningful exception when someone attempts to access it (this is preferable to a nondescript NullReferenceException that would otherwise occur).
2. Introduce an interface for InputBase types that wrap a single HTML element. If we want to share implementation between classes deriving from the interface, we can do so via an extension class.
3. Add BaseElementReference to each component where it makes sense, and don't introduce any new types.

@SteveSandersonMS @pranavkm Do you have any opinions about the best direction to take this?