[Blazor] Form events follow ups

[javiercn]

For preview 4, forms will bind by providing a name to the event. EditForm sets this event automatically based on the context from the component hierarchy.

We want to make form submission to work with default "form" elements, without having to call an API to define a named event for it.

Potential changes

• Support binding forms by default. We would special-case "onsubmit" within forms.
  • We would need to check the event name on event handlers to determine that they are onsubmit events. At that point, we would emit the same TrackNamedEvent handler with a default event name.
  • At the time of tracking, we can search the element to see if it defines a name, or id and use that.
  • With that, we get away without having to call SetEventName explicitly.
• The base renderer just emits calls to track the events, whether explict with SetEventName or "implict" which would only work for submit events in form elements.

How this would work for "plain forms" (without SetEventName)

• You define the form.
• You define the "action" attribute.
• You define the "name" or "id" attribute.

If you have a "name" or "id" attribute, the id attribute takes precedence.

If you define a "name" or "id" attribute, there is a "handler" parameter that needs to appear on the query string for us to be able to route the form.

We will not compute the "action" parameter for you on a default form. If your form has a name, it is your responsibility to figure out the right action value.

How this would work for EditForm.

We will continue to use the existing APIs and generate the name and action attributes for the form based on the CascadingModelBinders in the hierarchy. We can get rid of SetEventName if we want to at that point, but its worth keeping as a perf optimization (it avoid us having to do the look up for the name/id parameters on the element, but at that point, it becomes a "hint")

[javiercn]

We will need to have a way to disable the implicit form binding. Unlike with CascadingModelBinder and EditForm which take into account the hierarchy to compute what/where to dispatch to, a plain form element is responsible for this.

This means that if you are consuming a library from a third party and they decide to put a form in their app, giving it a name/id and without providing a way change it from outside, it can preclude the app from receiving POST requests.

There are legitimate scenarios for people giving a name or id to a given form, like interacting with the form in JS.

The difference with EditForm here is that EditForm is aware of the context its in within the hierarchy, and the developer can easily wrap the conflictive component in a CascadingModelBinder to disambiguate.

[javiercn]

Not having a default name ("") through the cascading model binder is also an option. We could choose to always have a handler that is based on the Page component that is being rendered. so ?handler=Index or ?handler=EditCustomer.

[javiercn]

Another point to be aware of when thinking about binding default form elements. Just having a form element will never be enough, since you need to put the request antiforgery token in the form body for the POST request to succeed.

[mkArtakMSFT]

@javiercn this has slept because it wasn't added to the project board.

[mkArtakMSFT]

What is pending to be done here?