14 min readJavaScript,
React,
CodingSome forms stay UI, while others quietly become rule engines. Here’s why these two different approaches exist and how to choose between them.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 data — a simple JSON schema — rather than a component tree.Same requirements, same conditional logic, same API call at the end. Then we’ll map exactly what moved and what stayed, and lay out a practical way to decide which model you should use, and when.The form we’re building:(Large preview)This form will use a 4-step flow:Step 1: DetailsFirst name (required),Email (required, valid format).Step 2: OrderUnit price,Quantity,Tax rate,Derived:Subtotal,Tax,Total.Step 3: Account & FeedbackDo you have an account? (Yes/No)If Yes → username + password, both required.If No → email already collected in step 1.Satisfaction rating (1–5)If ≥ 4 → ask “What did you like?”If ≤ 2 → ask “What can we improve?”Step 4: ReviewOnly appears if total >= 100Final submission.This is not extreme. But it’s enough to expose architectural differences.Part 1: Component-Driven (React Hook Form + Zod)Installationnpm install react-hook-form zod @hookform/resolvers @tanstack/react-query
