Dynamic Forms in React: When Simple State Is Not Enough

All forms start simple. A name field, an email field, a submit button. Then business requirements arrive. This field only appears if the user selects Option B. This validation rule changes depending on the account tier. This step only shows for international users. What started as a straightforward React component is now a conditional logic system with state dependencies that its original author no longer fully understands.

Understanding where your form sits on the complexity spectrum before you build it determines whether implementation takes three days or three weeks. At the simple end: controlled components with useState or React Hook Form. At the complex end: schema driven rendering with dependency resolution and server synced validation. Most developers default to the simple approach and then incrementally patch complexity onto it until the form becomes unmaintainable. The more productive path is identifying the form's eventual complexity at the design stage and choosing the right architecture from the start.

React's controlled component model, where form state lives in React state and every input is driven by a value and onChange pair, is the correct starting point for most forms. React Hook Form improves on this significantly: uncontrolled inputs with a register API reduce re renders, built in validation integration eliminates manual error state, and watch and setValue give enough flexibility for moderate conditional logic.

Controlled components become a liability when form structure itself is dynamic, when the list of fields is not known at compile time because it is driven by user role, server configuration, or a content management system. When the same form logic needs to render across multiple surfaces, a React web app, a React Native mobile app, and a third party integration, duplicating JSX for each is not viable. These are the specific conditions that push a form past what React Hook Form handles elegantly and into schema driven territory.

A schema driven form separates form structure, what fields exist and under what conditions, from form rendering, how those fields appear as UI. The form is defined as a JSON schema; a generic renderer interprets the schema and produces the appropriate React components at runtime.

This architecture enables forms configurable by non developers, forms that share logic across multiple surfaces, and forms that change frequently without requiring a code deployment or a developer to update JSX. The trade off is implementation complexity upfront. Libraries like React JSON Schema Form provide practical starting points; for projects with highly specific requirements, a custom schema resolver built on top of React Hook Form often produces better results.

Conditional field visibility is the feature that most clearly justifies schema driven forms. Expressing "show the VAT number field if the user selects a country in the EU" as declarative data rather than as a chain of if else statements in JSX makes the logic testable, auditable, and maintainable by someone who did not write the original form.

The most dangerous form bug is validation rules that exist on the client but not the server, or vice versa. A field that accepts invalid data on the server because client validation was updated without a corresponding server change is a data integrity and security problem, not merely a UX bug.

The solution is a shared validation schema. Using Zod or Yup, you define validation rules once and run them in both environments: the React client for immediate user feedback, and the Express API or Next.js Server Action for authoritative enforcement. When the rule changes, it changes in one place and propagates to both layers by design.

For Next.js projects specifically, Server Actions provide a clean pattern: the form submits directly to a server function that validates with the shared Zod schema, processes the data, and returns a typed result. React renders the result, success state or field level errors, without a full page reload. This pattern eliminates the most common form validation drift bug and makes the submission flow significantly simpler to reason about than a separate API route.