There is a mental model most React developers share without ever discussing it out loud. That forms are always supposed to be components. This means a stack like React Hook Form for local state, Zod for validation, and React Query for your backend submissions.

For the vast majority of forms—your login screens, your settings pages, your CRUD modals—this works incredibly well. Each piece does its job, they compose cleanly, and you can move on to the parts of your application that actually differentiate your product. We see this daily at Debugged Pro when reviewing client codebases.

But every once in a while, a form starts accumulating things like visibility rules that depend on earlier answers, or derived values that cascade through three fields. Maybe even entire pages that should be skipped or shown based on a running total.

You handle the first conditional with a useWatch and an inline branch, which is fine. Then another. Then you are reaching for superRefine to encode cross-field rules that your Zod schema cannot express in the normal way. Then, step navigation starts leaking business logic. At some point, you look at what you have built and realize that the form is not really UI anymore. It is more of a decision process, and the component tree is just where you happened to store it.

Debugged Pro Explains: When Forms Become Decision Engines

This is where the mental model for forms in React breaks down, and it is really nobody's fault. The React Hook Form and Zod stack is excellent at what it was designed for. The issue is that we tend to keep using it past the point where its abstractions match the problem because the alternative requires a different way of thinking about forms entirely.

This article is about that alternative. To show this, we will build the exact same multi-step form twice: First with React Hook Form plus Zod wired to React Query for submission, and second with SurveyJS, which treats a form as data—a simple JSON schema—rather than a component tree. If you want to see more about our specific implementation strategies, check out the web development services we offer at Debugged Pro.

The form we are building will use a four-step flow. Step 1 focuses on Personal Details, requiring a first name and a valid email format. Step 2 handles the Order, requiring a unit price, quantity, tax rate, and derived fields for subtotal, tax, and total. Step 3 covers Account and Feedback. It asks if the user has an account. If yes, it requires a username and password. If no, it uses the email already collected in step 1. It also asks for a satisfaction rating from 1 to 5. If the rating is 4 or higher, it asks what the user liked. If 2 or lower, it asks what can be improved. Step 4 is a Review step that only appears if the total is greater than or equal to 100.

This is not extreme. But it is enough to expose architectural differences between component-driven and data-driven approaches.

Part 1: The Component-Driven Approach (React Hook Form + Zod)

A comparative line graph illustrating the performance and rendering efficiency of building dynamic forms in React versus Next.js, from the Debugged Pro guide. — Performance Comparison: React vs. Next.js for Dynamic Form Development

Let us start with the Zod schema, because that is usually where the shape of the form gets established. For the first two steps—personal details and order—the schema is straightforward. You define strings, numbers, and basic constraints.

However, once we reach Step 3, things get complicated. Zod is designed to validate data structures, not application flow. To handle the conditional logic of requiring a password only if the user has an account, we have to use Zod's discriminatedUnion or superRefine. It looks something like this:

const step3Schema = z.object({ hasAccount: z.boolean(), username: z.string().optional(), password: z.string().optional(), rating: z.number().min(1).max(5), feedback: z.string().optional() }).superRefine((data, ctx) => { if (data.hasAccount && !data.password) { ctx.addIssue({ code: z.ZodIssueCode.custom, message: "Password required", path: ["password"] }); } });

This works, but notice how the business logic is now tightly coupled to the validation schema. According to best practices highlighted by Mozilla MDN web docs on forms, keeping validation and business logic separate is crucial for maintainability.

Inside the React component, things get even messier. To handle the derived values in Step 2, you have to watch the inputs using React Hook Form's useWatch. Every time the quantity or unit price changes, you calculate the total. If the total is over 100, you set a state variable to show Step 4. This causes React to re-render. If you have a massive form, these constant re-renders can degrade performance. We have written extensively about this issue in our advanced React tutorials at Debugged Pro.

Furthermore, step navigation becomes a massive switch statement. When the user clicks 'Next', you have to validate only the fields in the current step. React Hook Form provides the trigger method for this, but managing the array of field names for each step manually is prone to human error.

Part 2: The Data-Driven Alternative (SurveyJS)

Now let us look at the alternative. Instead of writing React components and wiring up state manually, what if we just described the form as a JSON object? This is the core philosophy behind SurveyJS and similar data-driven form libraries. As noted in recent TechCrunch developer news, enterprise teams are increasingly shifting toward headless, data-driven UI architectures to speed up development.

In this model, your entire four-step form is defined in a single JSON schema. You do not write a custom React component for the email field. You do not write a useWatch hook to calculate the total. You simply define the rules in the data.

const formJson = { pages: [ { name: "step1", elements: [ { type: "text", name: "firstName", title: "First Name", isRequired: true }, { type: "text", name: "email", title: "Email", inputType: "email", isRequired: true } ] }, { name: "step2", elements: [ { type: "text", name: "price", inputType: "number" }, { type: "text", name: "qty", inputType: "number" }, { type: "expression", name: "total", expression: "{price} * {qty}" } ] } ] };

Notice the expression type in Step 2. SurveyJS has a built-in evaluation engine. It handles the derived value automatically, without triggering React re-renders. The logic lives entirely inside the JSON configuration.

For Step 3's conditional visibility, you simply add a visibleIf property to the password field: visibleIf: "{hasAccount} = true". The library handles the rest. You do not need Zod's superRefine. You do not need complex local state. The form is purely declarative.

This approach shines when you need to serialize the form and save it to a database. Because the form is just JSON, you can store it, version it, and send it over an API. A product manager can literally change the order of the questions or adjust a validation rule without touching the React codebase. To understand more about how we implement version control for JSON configurations, you can read our methodology on the Debugged Pro About Us page.

Debugged Pro's Final Verdict: Which Should You Choose?

We are not saying you should throw away React Hook Form. In fact, for 80 percent of the forms you build, React Hook Form and Zod remain the absolute best choice. They provide exceptional type safety, great developer ergonomics, and minimal overhead for standard data entry tasks.

However, as we frequently advise at Debugged Pro, you must recognize the tipping point. When your component files grow past 500 lines solely because of useWatch hooks, conditional rendering branches, and step navigation state, you have crossed the line. You are no longer building a UI component; you are building a proprietary workflow engine.

If your application relies heavily on dynamic questionnaires, multi-page assessments, or surveys where the business logic changes frequently, adopting a data-driven model like SurveyJS will save you hundreds of hours of maintenance. It forces a clean separation of concerns: the library handles the rendering and state machine, while your JSON schema acts as the single source of truth for the business rules.

Building dynamic forms in React and Next.js does not have to be a nightmare of spaghetti state. By choosing the right architectural model for the specific problem at hand, you can keep your codebases clean, performant, and highly scalable.