driven-form

Showcase

Seven forms, one engine.

Every card below is a schema the engine actually runs. Open one, edit the JSON, and watch the form follow.

Any form that asks follow-up questions

Conditional questions

A field appears when another is answered a certain way, and disappears — with its validation — when it is not. The most common frontend ticket there is, expressed as two lines of JSON.

  • show
  • required
  • expressions
Open in playgroundLong forms with optional coverage

Insurance quote

Sections, side-by-side rows, a country-specific field, and an opt-in section whose fields unmount entirely when switched off — so hidden fields are never validated.

  • sections
  • containers
  • toggle
Open in playgroundPricing, quotes, invoices

Order sheet

Quantity × price → subtotal → discount → taxable → tax → total. Four levels of derived values, settled in a single write rather than one render pass per link.

  • calculateValue
  • calc graph
Open in playgroundAnything with a variable number of rows

Cap table

Add and remove directors, each row validated in its own scope, with a form-level total that sums across every row as you type.

  • repeater
  • sum()
  • scoped validation
Open in playgroundRegistration and onboarding

Sign-up with rules

Built-in validators, a rule that only runs on blur instead of every keystroke, and a checkbox that blocks submit until it is ticked.

  • validation
  • validateOn
Open in playgroundAnything that has to ask a server

Username check

An async rule that waits for blur instead of firing on every keystroke, a cross-field password match, and a domain format rule — all registered once and referenced by name from the schema.

  • async
  • validateOn: 'blur'
  • custom validators
Open in playgroundThe form your users complain about

Forty-five fields

Four sections, per-section totals and a grand total. Type in one field and open the Renders tab: only that field and its declared dependents move. Everything else holds at one.

  • performance
  • render isolation
Open in playground

The headless contract

Same JSON. Switch the design.

Three sets of components registered for the same field types. Press a tab: the labels, the choices and the whole visual language change, and the schema on the left doesn't move a character. Your values, validation and conditional fields survive the swap, because the engine isn't rebuilt — only re-rendered with different components.

Try it: change the seats or switch to Personal — then press another design. Everything you entered is still there, and the conditional fields still behave the same way.

Things that happen over time

Async checks, and what follows them.

Some behaviour can't be shown in a code block because it unfolds over time. An async rule that waits for blur instead of firing on every keystroke. A submit that runs every rule and scrolls to the first failure. An error your server pushes back after the form looked fine. The log on the right timestamps each one, so the timing is something you can read.

Type admin into Username and press Tab — watch the round trip. Then press Submit on the empty form, orSimulate a 409 to see a server error arrive.

Anything that emits JSON

Describe a form. Get a schema.

Pick a description and watch the schema that satisfies it. Then open it and change it.

Pick a description above.

These schemas are written by hand, not generated — there's no model behind this box. The point is what it implies: a form is a JSON document, so anything that can produce JSON can produce a form. A backend, a CMS, a spreadsheet export, or a model.