Validate passing unmatched attributes to Blazor form components

rynowak commented 5 years ago

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

[x] Works with EditForm
[x] Works with InputCheckbox
[x] Works with InputDate
[x] Works with InputNumber
[x] Works with InputSelect
[x] Works with InputText
[x] Works with InputTextArea
[x] Works with ValidationMessage
[x] Works with ValidationSummary
[x] Preserves original case of unmatched attributes
[x] Forwards unmatched attributes regardless of order
[x] 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: https://github.com/aspnet/AspNetCore/issues/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 commented 5 years ago

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 commented 5 years ago

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

"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 />
```
"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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

dotnet / aspnetcore