-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Closed
Labels
area-blazorIncludes: Blazor, Razor ComponentsIncludes: Blazor, Razor ComponentsenhancementThis issue represents an ask for new feature or an enhancement to an existing oneThis issue represents an ask for new feature or an enhancement to an existing onefeature-full-stack-web-uiFull stack web UI with BlazorFull stack web UI with Blazor
Milestone
Description
While we have now implemented support for EditForm
usage in particular patterns, this issue is about enabling support for more basic, unopinionated form post handling. Capabilities to enable:
- Receive an arbitrary HTTP POST to a component endpoint
- access HttpRequest and thereby access Form, Headers, Cookies, etc.
- ... and manually perform model binding procedurally against that incoming Form data
- ability to disable enforcing antiforgery validation at the per-endpoint level
- might be already covered in Blazor antiforgery #46987
- access HttpRequest and thereby access Form, Headers, Cookies, etc.
- Submit a plain
<form>
via POST to the page you're on- receive the values via [SupplyParameterFromForm]
- partly already done, but the API may need some tweaks to enable the following
- they are available by the time
OnInitialized
runs - optionally set a form field name,
[SupplyParameterFromForm("acceptsTerms")]
, otherwise defaults to property name- either way, it automatically respects the cascading name prefix, if any
- optionally set a handler name,
[SupplyParameterFromForm(Handler = "myform")]
, otherwise accepts any POST
- parts of the form can be split into a child component (with developer managing field name prefixes manually)
- Should be covered automatically by the above features
- can emit an antiforgery token
- Should be already covered by Blazor antiforgery #46987, unless we decide also to emit this automatically during prerendering based on the
action
being an internal URL
- Should be already covered by Blazor antiforgery #46987, unless we decide also to emit this automatically during prerendering based on the
- can specify a handler name (already done, but needs some tweaks to enable all the following)
- make it optional - if not set, defaults to some fixed string such as empty, which is a valid handler name
- TBD: should we actually make nonempty handler name a prerequisite if you have
method="post"
?
- TBD: should we actually make nonempty handler name a prerequisite if you have
- nonhierarchical - it's enough to say you must pick a unique enough name
- if set, automatically emitted as a hidden form field during SSR, to avoid interfering with URLs
- probably should call this a "form name" or "form handler name" not just a "handler name" for clarity
- make it optional - if not set, defaults to some fixed string such as empty, which is a valid handler name
- triggers any
@onsubmit
handler once the page reaches quiescence- if all matching handlers (based on optional handler name) are for the same
(target, MethodInfo)
pairs, invoke it - otherwise throw ambiguous match error
- handles
@onsubmit
event exceptions in an ErrorBoundary-aware way (Blazor SSR form post handling: integrate errors with ErrorBoundary #47903)
- if all matching handlers (based on optional handler name) are for the same
- receive the values via [SupplyParameterFromForm]
- Optionally use
Input*
components- TODO: Should
@bind-Value=lambda
really generate a name by default? This only works in basic cases and we don't have a design proposal to scale this up to forms split into child components or if using custom edit components. - If we do continue generating field names automatically, have optional mechanism for cascading a name prefix (e.g.,
CascadingModelBinder
, but change it not to be templated to avoid context clash)
- TODO: Should
- Optionally use
EditForm
- During SSR, if we are in a POST matching the handler name:
- automatically attaches any modelbinding errors as a
ValidationMessageStore
(ideally this should be something you can do procedurally to anEditContext
too, rather than being exclusive to anEditForm
) - supports the same
@onsubmit
triggering as a plain<form>
, thereby triggering validation andOnValidSubmit
etc
- automatically attaches any modelbinding errors as a
- During SSR, if we are in a POST matching the handler name:
Earlier version of this issue description, all of which should be covered above
Expand
- Receiving an arbitrary POST request that populates
[SupplyParameterFromForm]
parameters - Receiving a plain HTML
<form>
post that does that - Having a plain HTML
<form>
trigger an@onsubmit
handler - Ensuring that
[SupplyParameterFromForm]
can work with simple scalar values, with the field name taken from the property name (no form name or prefix required) - Ensuring that
[SupplyParameterFromForm]
can work with complex objects given appropriate name prefixes - Ensuring the error experience around ambiguous form posts is clear (e.g., form name is required if and only if a form has both
method=post
and nonempty@onsubmit
) - Supporting patterns for one-form-multiple-actions and multiple-forms-one-action
- Where possible simplifying the developer experience, e.g., making sure CascadingModelBinder isn't required for basic scenarios, and perhaps streamlining functionality by reducing the number of concepts or parts of implementation required
Metadata
Metadata
Assignees
Labels
area-blazorIncludes: Blazor, Razor ComponentsIncludes: Blazor, Razor ComponentsenhancementThis issue represents an ask for new feature or an enhancement to an existing oneThis issue represents an ask for new feature or an enhancement to an existing onefeature-full-stack-web-uiFull stack web UI with BlazorFull stack web UI with Blazor