Provide a way for Nimble Blazor components to request focus

[epetersoni]

🙋 Feature Request

😯 Problem to Solve

There is an ask that on opening a NimbleDialog, we give focus to a particular Nimble field control within the dialog. I don't think this is possible with Nimble Blazor fields at the moment without resorting to some hacky JS that understands the internal implementation of the control.

💁 Proposed Solution

Some Nimble Blazor components - at least fields - expose a FocusAsync method. The internal implementation would need to find the ElementReference for the focusable part of the control and call the .NET FocusAsync method on it.

Exposing the ElementReference itself (or a wrapped version of it) could also be an option. We do have some bUnit test code that finds the input element for a field and invokes events like Change on it.

📋 Tasks

[rajsite]

When a dialog opens the first focusable control inside the dialog should gain focus. Can see it via the cursor in this example: https://jsbin.com/sixetez/3/edit?html,output

My question is are you seeing the first focusable control gain focus or does the blazor integration / windowing change the behavior?

If the first focusable control is immediately focused as expected, is there some other behavior being requested?

[epetersoni]

I am not seeing the first focusable control immediately focused. I suspect this is because the dialog content is being populated dynamically, and is not yet there at the initial dialog render.

[rajsite]

I am not seeing the first focusable control immediately focused. I suspect this is because the dialog content is being populated dynamically, and is not yet there at the initial dialog render.

Are you able to delay the call to ShowAsync until after the dialog contents are populated?

[atmgrifter00]

Regarding the autofocus solution, I'll mention that not all of our components that can provide that behavior do (e.g. the NimbleNumberField), and further not all components that should provide that behavior do (e.g. the NimbleSelect/NimbleCombobox). The latter issue being present primarily due to FAST. We need a separate issue that tracks this (I will create it).

I suspect that we likely should ultimately expose access to the ElementReference on our component APIs. This is what Microsoft does for all of their input components at least.

[rajsite]

Regarding the autofocus solution, I'll mention that not all of our components that can provide that behavior do (e.g. the NimbleNumberField), and further not all components that should provide that behavior do (e.g. the NimbleSelect/NimbleCombobox). The latter issue being present primarily due to FAST. We need a separate issue that tracks this (I will create it).

I suspect that we likely should ultimately expose access to the ElementReference on our component APIs. This is what Microsoft does for all of their input components at least.

Chatted with Meyers offline and a couple points:

• The autofocus attribute is actually a native DOM attribute and behavior. We seem to be exposing it inconsistently and it seems to behave inconsistently on our components.

  But autofocus is an auxiliary behavior. It lets you pick the focus target on dialog open instead of having the focus target be the first focusable target. We need to first get the default first focusable target behavior working before trying to be fancier and choosing a different target.

• Sounds like exposing the ElementReference was generally used for the ExtensionMethod FocusAsync. In general we are trying to avoid Blazor component users needing to know details of the Razor Component implementation so I think we'd prefer to implement FocusAsync on the Razor component directly instead of exposing implementation details / an ElementReference.