Validate passing unmatched attributes to Blazor form components

[rynowak]

Summary

Preview 6 adds the ability to pass arbitrary attributes to our form components and have them flow through to the underlying HTML element associated with the component.

Example: (the ability to specify placeholder is the usage of the new feature)

<EditForm Model="@exampleModel" OnValidSubmit="@HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <InputText id="name" bind-Value="@exampleModel.Name" placeholder="Enter your name"/>

    <button type="submit">Submit</button>
</EditForm>

@functions {
    private ExampleModel exampleModel = new ExampleModel();

    private void HandleValidSubmit()
    {
        Console.WriteLine("OnValidSubmit");
    }
}

For now Class and Id are still defined as component parameters. This will be removed in preview 7 and these attributes will also use the unmatched attributes support.

For now the completion experience on the InputText element won't offer you attributes like placeholder in VS.

Checklist

• Works with EditForm
• Works with InputCheckbox
• Works with InputDate
• Works with InputNumber
• Works with InputSelect
• Works with InputText
• Works with InputTextArea
• Works with ValidationMessage
• Works with ValidationSummary
• Preserves original case of unmatched attributes
• Forwards unmatched attributes regardless of order
• Duplicate attributes differing only in casing results in a build error

References

• docs: https://docs.microsoft.com/en-us/aspnet/core/blazor/forms-validation?view=aspnetcore-3.0
• design: Syntax for writing a dictionary of attributes onto an element #5071 (this is just background, you'll see things there are coming preview 7)
• code: https://github.com/aspnet/AspNetCore/tree/master/src/Components/Components/src/Forms/InputComponents

[rynowak]

note: this validation should be considered blocked until we have a d16.2 build with all of the editor fixes in it. Since it touches the editing experiences, we should do the validation of this feature once those things land.

[ryanbrandenburg]

I'm mostly done here, I found one issue and want to make one clarification:

1. "Preserves original case of unmatched attributes" does not seem to hold true. If I put

<InputText Id="name" @bind-Value="@exampleModel.Name" firstOrLast="first" />

with will be output in html as:

<input id="name" firstorlast="first />

2. "Forwards unmatched attributes regardless of order" I'm not 100% clear on what this means. I assume it means "even if the unmatched attributes are in something other than alphabetical order, they should still all be added."

1 doesn't seem like a blocker in either case, but definitly something @SteveSandersonMS should have a look at,.

If I get confirmation of my interpretation of 2 this will be good to go.

[ryanbrandenburg]

2 didn't mean what I thought it did (actually meant that if we have an unbound parameter, a bound parameter, then further unbound parameters they should all end up in the right place) but it's been verified.

Leaving this option to get @SteveSandersonMS's opinion on "Preserves original case of unmatched attributes", but that's relatively minor, so we can count this as done for release purposes.

[rynowak]

Preserves original case of unmatched attributes", but that's relatively minor, so we can count this as done for release purposes.

@SteveSandersonMS is there something that we're doing in the JS code to force attributes to lower case? I found this behaviour surprising and the compiled code has the original case.

[ryanbrandenburg]

I think this is just something in the way that browsers handle attributes: If I just create a plain .html file with weirdly cased attributes they get lower-cased in Chrome and Firefox.