FormSanity Demos

Submission

This page exercises the submission protocol against the mock server. Open the browser's network panel and follow the walkthrough below the form.

The page URL's query string is forwarded to the form action, steering the server's envelope: accepted (default) · invalid · expired · redirect · error · handler.

  • Name
Freeform Rows

Rows authored outside the ul grammar: a data-fs-field wrapper is a row wherever it stands. The referral code sends its errors to a designated element with data-fs-error-to.

Walkthrough

Everything interesting here happens in the network panel — open it first, then:

  1. Watch what the client sends. Submit, click the submit request, and open its payload. Alongside the form values sit csrf: demo-token — a hidden field round-tripped byte for byte — and token: tok_123, injected by a pre-submit hook and found in no markup anywhere. Select two colors first and colors arrives as an array; the compound name arrives as two fields. What the server receives is not just the fields on the screen.
  2. Watch what the server answers. The same request's response is the protocol's envelope: {"formsanity": 2, "status": "accepted", "message": "Thanks!"}. The green banner is the client rendering it.
  3. Watch a rejection round-trip. Follow the invalid link above, submit again, and the request goes red with a 422. Its response carries an errors array naming the email field — and the page has rendered that exact error as a bubble on the email field. A server-side verdict finding its way back to the right control is the protocol's other half. Press Tab to leave the field and the bubble stays, with Submit closed: the engine cannot check the server's judgment again. Edit the email and the error clears for the next submission.
  4. An error with no field to edit. Follow the expired link and submit. The server's error names the hidden csrf field. The person cannot edit that field, so the message appears as a line in the status region, and Submit stays open for another try.
  5. The other two scenarios. redirect: the accepted envelope carries a redirect and the client follows it. error: a 500, and the status region takes its failure state instead of pretending.
  6. A handler in place of the request. Follow the handler link and submit: no submit request appears, because a submit handler in the page answers in its place. It refuses the prefilled example.com address with an invalid envelope, and the bubble lands on Email as a server's would. Change the address and submit again for its accepted envelope. The uniqueness check on Email still goes to the server: a handler takes the place of the submission request only.
  7. The unique sub-protocol, no submit needed. Put taken@example.com in Email and press Tab: a unique request fires and the field flags "already in use". Do it three times fast and the third request is a 429 — the mock rate-limits on purpose, and the client backs off silently rather than flag a field it could not check.