Building Dynamic Forms In React And Next.js

This article is a sponsored by SurveyJS There’s 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 (minimal re-renders, ergonomic field registration, imperative interaction). Zod for validation (input correctness, boundary validation, type-safe parsing). React Query for backend: submission, retries, caching, server sync, and so on. And for the vast majority of forms — your login screens, your settings pages, your CRUD modals — this works really 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. 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’re reaching for superRefine to encode cross-field rules that your Zod schema can’t express in the normal way. Then, step navigation starts leaking business logic. At some point, you look at what you’ve built and realize that the form isn’t really UI anymore. It’s more of a decision process, and the component tree is just where you happened to store it. This is where I think the mental model for forms in React breaks down, and it’s really nobody’s fault. The RHF + 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’ll build the exact same multi-step form twice: With React Hook Form + Zod wired to React Query for submission, With SurveyJS, which treats a form as d