Dynamic form

What is a dynamic form?

A dynamic form builds its inputs from data rather than from fixed markup. Instead of writing a text input, then an email input, then a textarea by hand, you keep an array of field definitions and let one component render whatever that array describes. Change the data and the form changes; the component stays the same.

That is the whole idea, and it is worth being precise about it. The field set still resolves to a concrete list of inputs, in this template a name, an email, and a message, and posts once to Formpaste as a single submission. What is dynamic is where those inputs come from: a schema you can edit, not JSX or template markup you have to touch every time a field is added, removed, or reordered.

When to use it

Reach for a dynamic form when the same rendering logic has to serve many different field sets. If you maintain several forms that differ only in which fields they show, driving them from schemas lets one component power all of them, and adding a field becomes a data edit rather than a code change.

It also fits forms whose fields are configured elsewhere, by an admin panel, a config file, or a content model, and read at build or render time. If your form is a single fixed set of inputs that rarely changes, a plain hard-coded form is simpler and easier to reason about. The dynamic pattern pays off when the field set is the thing that varies.

What to include

This template ships with a straightforward field set to show the pattern clearly. Name is a required text field, email is a required email field, and message is an optional textarea, rendered from schema definitions rather than written out as static markup. Swap or extend that array and the same component renders the result; the submission still goes to Formpaste as one payload.

Two things matter more than the specific fields. First, keep the hidden access key input in the payload so however the schema changes, the submission still authenticates. Second, name each schema entry clearly, because the field name, not the label, is what shows up in your inbox and your exports. Formpaste stores whatever names you send, so meaningful names like name, email, and message keep your submissions readable even as you change labels or reorder the schema.

Tips for a schema-driven form

Treat field names as your data contract. The name is what lands in your inbox and CSV, so choose it deliberately and keep it stable even when the label or order changes. A schema entry renamed from “message” to “field_4” turns a readable submission into a guessing game.

One component, one submit, any shape. However many fields the schema defines, render them through the single component and post once. Resist splitting the submission per field; a dynamic form is still one request to Formpaste, which is what keeps your inbox tidy no matter how the schema grows.

Keep the schema as the source of truth. When a field needs to change, change the data, not the markup. That discipline is the entire benefit of the pattern, and it disappears the moment you start hard-coding one-off inputs alongside the schema-driven ones.