COMPONENTS FEATURE
The form component
A form whose fields are signed into the page, re-validated on the server on submit, then gated by action authorization before the action runs.
The form component
A form is where untrusted input meets your domain, so it cannot be a client-only affair. platform.form aggregates fields, validates them in the browser for immediate feel, and re-validates authoritatively on the server before any action runs.
The signed submit pipeline
The form signs its field definitions — the rules and the action — into the page (HMAC, the same substrate as the event runtime). On submit:
- Client-local validation runs first, for instant feedback.
- The browser posts; the server parses the signed definitions from
cfg.f. - Authoritative validation re-runs against the submitted values — the client cannot have changed the rules.
- The action is gated: authorization check → security policy (CSRF / session) → action invocation. The client cannot smuggle a different action; it is signed too.
- The reply patches the form status and
ui-state.
The demo above renders the structure from real field components; a wired form adds the action and the pipeline above.
Client validation alone is a nicety any user can bypass; server validation alone feels sluggish. Signing the definitions and validating on both sides gives immediate feedback and tamper-proof correctness — over the same signed-context substrate as the rest of the UI. One architecture, not a bespoke form backend per screen.
How it works
The form signs its field definitions — rules and action — into the page (HMAC, like the event runtime). On submit the client runs local validation for instant feedback, then posts; the server parses the signed definitions from cfg.f, re-runs validation authoritatively against the submitted values, and only then gates the action: authorization check → security policy (CSRF / session) → action invocation. The reply patches the form status and ui-state. A client can neither change the rules nor smuggle a different action — both are signed.
Why it matters
Client validation alone is a UX nicety any user can bypass; server validation alone feels sluggish. Signing the definitions and validating on both sides gives immediate feedback and tamper-proof correctness — over the same signed-context substrate as the rest of the UI. One architecture, not a bespoke form backend per screen.