[Blazor] Initial support for [SupplyParameterFromForm]

[javiercn]

Adds support for binding strings via [SupplyParameterFromForm] any other type that requires conversion has been explicitly left out.

Contributes to #46688

[MackinnonBuck]

Looks good to me, just a few questions.

[SteveSandersonMS]

I'm trying to make sense of whether this can interfere with unrelated [CascadingParameter] scenarios. It looks like it might do.

• Right now I know you've limited this so that FormValueSupplier.CanBind only returns true for string. So it looks like it would interfere with any case where someone has a parameter like [CascadingValue] public string Something { get; set; }. That's a pretty niche scenario, but still would be very weird for a form value to show up.
• If we want to extend in the future also to binding arbitrary types to model-bind a form post, then maybe it would start interfering with everything as it would automatically want to supply values for all types. I'm not 100% sure about this but it seems possible.

The two main mitigations I could think of are:

1. We could require these parameters to have a special type, e.g., [SupplyParameterFromForm] public FormData Form { get; set; } (possibly also FormData<T> for model binding other types, which also gives a way to trigger binding procedurally and possibly collect validation errors)
2. Or, extend the ICascadingValueComponent interface to have another overload of CanSupplyValue which also accepts the attribute on the parameter (i.e., the CascadingParameterAttribute or derived attribute type), and then the logic here can be prefixed with if (thatAttribute is not SupplyParameterFromFormAttribute) return false and we then know for sure it's not interfering with anything else, and we're not incurring any perf cost of instantiating strings for every unrelated named [CascadingParameter] like on line 141.

[javiercn]

@SteveSandersonMS Mackinnon is working on that part. We'll very likely do 2. Which allows us to filter.

[javiercn]

I am scoping that part out of my PR.

[SteveSandersonMS]

I find it difficult to review this PR in isolation because it's adding things we know we don't want, so would have to combine it with a follow-up PR to make sense of whether the net result actually adds the right things. If you feel that's definitely the best way to proceed then OK, but my preference would be to split things up into small items which are each individually correct, for example first making the tweak to generalize cascading parameters, then as a follow-up building [SupplyParameterFromForm] on top of that.

[SteveSandersonMS]

Is there a design description somewhere for how we're going to handle:

• Binding to custom model types
• Integrating with forms and validation

Do you have an example of a canonical SSR form that will show server-side validation messages on post?

[javiercn]

@SteveSandersonMS sample form https://github.com/dotnet/aspnetcore/blob/javiercn/blazor-named-forms/src/Components/Samples/BlazorUnitedApp/Pages/Index.razor

I am trying to work out the prototype in small chunks, so there will be missing parts and pieces that will change as I dive deeper into specific implementations.

[SteveSandersonMS]

@SteveSandersonMS sample form https://github.com/dotnet/aspnetcore/blob/javiercn/blazor-named-forms/src/Components/Samples/BlazorUnitedApp/Pages/Index.razor

That looks good, thanks. How do the validation messages get into the edit context for the form? There doesn't appear to be any code in the app saying this specific form is meant to be associated with data from the form post.

[javiercn]

That looks good, thanks. How do the validation messages get into the edit context for the form? There doesn't appear to be any code in the app saying this specific form is meant to be associated with data from the form post.

The values are bound within a binding context, the form is rendered within that binding context, so the errors are populated from it.

https://github.com/dotnet/aspnetcore/blob/javiercn/blazor-named-forms/src/Components/Components/src/Binding/BindingContext.cs

https://github.com/dotnet/aspnetcore/blob/javiercn/blazor-named-forms/src/Components/Forms/src/BindingContextValidator.cs

The BindingContextValidator and Antiforgery are automatically plugged in by EditForm

https://github.com/dotnet/aspnetcore/blob/javiercn/blazor-named-forms/src/Components/Web/src/Forms/EditForm.cs#L147-L150

Antiforgery flows transparently from the server to webassembly via PersistedComponentState https://github.com/dotnet/aspnetcore/blob/javiercn/blazor-named-forms/src/Components/Web/src/Forms/Antiforgery/AntiforgeryStateProvider.cs so your form renders the same in server and webassembly.