Expose ReferenceElement for qualified input components

[uabarahona]

Summary

As discussed on #24446 this PR is to expose "InputElement" which is a ReferenceElement, some notes to take into account:

• @MackinnonBuck I have stick with InputElement name everywhere to keep consistency. [I think it's fine as select is also a input, but I can change the name for select if it is really needed]
• I have made the set protected to support inheritance

Addresses #24446

[MackinnonBuck]

Looks good! I had a couple small comments. @pranavkm, could you take a look?

[pranavkm]

This looks really good. Any chance we could add one test that verifies this works end-to-end? Something that verifies that you could Focus on the input element using this mechanism?

[uabarahona]

Tests were added and they brought up an issue where InputRadio was being re-rendered always no matter what, this due InputRadioGroup sets InputRadioContext as key but InputRadioContext didn't have a way to compare so the diff process was taking the InputRadioGroups always as different.

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

Line 17 in 9177683

private InputRadioContext? _context;

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

Lines 45 to 48 in 9177683

	builder.OpenComponent<CascadingValue<InputRadioContext>>(0);
	builder.SetKey(_context);
	builder.AddAttribute(1, "IsFixed", true);

[MackinnonBuck]

@barahonajm The problem you're describing is intended behavior - the radio buttons are re-rendered when the _context changes so validation styling is applied. We might be able to investigate a way to preserve the radio button instances when re-rendering so ElementReferences don't get invalidated. Was the issue in using the ElementReference itself or just the E2E tests (i.e. StaleElementReferenceException)?

[uabarahona]

@MackinnonBuck I see, let me ask a little question shouldn't the radiogroup be re-renderd only when the _context changes? because in my case both _context old and new have exactly the same content but since they are always initialized as a new class they appear as different, that is because I added a equals to InputRadioContext.

Here the code on InputRadioGroup:

protected override void OnParametersSet()
{
    var groupName = !string.IsNullOrEmpty(Name) ? Name : _defaultGroupName;
    var fieldClass = EditContext.FieldCssClass(FieldIdentifier);
    var changeEventCallback = EventCallback.Factory.CreateBinder<string?>(this, __value => CurrentValueAsString = __value, CurrentValueAsString);

    _context = new InputRadioContext(CascadedContext, groupName, CurrentValue, fieldClass, changeEventCallback);
}

The issue on E2E test is that the FocusAsync() does not work at all for radio buttons since they get re-render after the focus is applied

[MackinnonBuck]

@barahonajm it must be because a new InputRadioContext is created each time the parameters are set, so it is therefore a new key. One solution could be to get rid of the IsFixed attribute for the CascadingValue and remove the key as well, but I'm not completely sure what the performance implications of this are. @pranavkm, do you have any suggestions for this?

[uabarahona]

Yes, that's the reason I was not able to explain it well 😃, I added an equals to InputRadioContext and that solved the issue, but I don't know too the performance implications

[pranavkm]

We discussed options and think it might be easier to not have the InputRadio.ElementReference to start with. We can always fix the implementation in the future to have this work.

[uabarahona]

Got it, I have removed the Inputradio from the PR

[SteveSandersonMS]

@pranavkm When completing this PR, please also consider adding support for #28533 and closing that as resolved.

[pranavkm]

Thanks @JuanElements for your PR. I've created another PR based on your changes here - #29555. We'll use that to track this to completion.