React Hook Form + Zod Validation UI: Patterns to Clone

What does clone-worthy form validation actually look like?

Think of the last form that felt good. Errors did not appear while you were still typing your email; they appeared when you left the field broken, and vanished the instant you fixed it. Every message sat next to its field and said something specific (“password needs a number,” not “invalid input”). The submit button worked when it said it did.

None of that is an accident, and all of it is reproducible with two libraries that now define the category: React Hook Form (51,731,632 npm downloads the week this was written, MIT-licensed) and Zod (185,357,947 the same week). The pairing matters more than either half: the schema owns the rules, the form library owns the timing, and components stay dumb.

Why schema-first beats validation-in-components?

Because rules drift. A required-field check in one component, an email regex in another, a max length only the backend knows about: that is how forms rot into “it let me submit but the server said no.” A Zod schema centralizes every rule, infers the TypeScript types so the form values cannot lie, and validates the same payload again at the API boundary:

const SignupSchema = z.object({
  email: z.string().email("Enter a valid email address"),
  password: z.string().min(12, "At least 12 characters").regex(/\d/, "Add a number"),
  iban: z.string().regex(IBAN_RX, "That IBAN doesn't look right"),
});
type Signup = z.infer<typeof SignupSchema>;

const form = useForm<Signup>({
  resolver: zodResolver(SignupSchema),
  mode: "onBlur",            // mark fields when the user leaves them
  reValidateMode: "onChange" // then heal errors live
});

This is the same single-source-of-truth discipline as JSON mocking structures for Claude builds, and the two compose: hand an agent the schema and the fixture together and the generated form, mocks, and API client all agree on what valid means. Error copy lives in the schema too, which is what keeps it specific; the generic “invalid input” voice appears exactly when messages are written far from the rules they describe.

Which timing and placement patterns make it feel right?

Pattern	The rule	Why it wins	Verdict
Blur-then-live timing	Validate on blur; revalidate touched fields on change	No scolding mid-typing, no submit ambush, instant healing	The default; RHF’s mode + reValidateMode give it for free
Inline errors	Message directly under its field, field outlined	Zero hunting; screen readers announce via the field	Never a summary-only toast
Specific copy from the schema	Each rule carries its own message	”Add a number” is actionable; “invalid” is noise	Write messages where rules live
Honest submit	Tappable submit that validates and scrolls to first error	A silently disabled button is uninterrogable	Prefer over disabled; if disabling, show why
Async checks debounced	Username-taken style checks on blur, spinner inline	Keystroke-level API calls punish typing	Cache results; never block typing

The screens themselves scaffold fastest from a finished design: pick a form or onboarding design from VP0, paste its link into Claude Code or Cursor with the schema, and the agent generates React components with fields, error placement, and submit states already aligned to your rules. The library is free, and feeding design plus schema is precisely the two-structure briefing that stops agents inventing their own validation.

What changes in React Native?

The logic transfers untouched; the wiring does not. Native inputs are not DOM fields, so each TextInput wraps in a Controller, with the error rendered as a Text beneath it:

<Controller control={form.control} name="email"
  render={({ field, fieldState }) => (
    <>
      <TextInput value={field.value} onChangeText={field.onChange}
        onBlur={field.onBlur} autoCapitalize="none" returnKeyType="next" />
      {fieldState.error && <Text style={s.error}>{fieldState.error.message}</Text>}
    </>
  )} />

Three React Native specifics earn attention. Keyboard flow: returnKeyType plus refs so each field hands focus to the next, because tab order does not exist on a phone. Scroll-to-error: on submit failure, scroll the first broken field into view above the keyboard, the mobile equivalent of focusing it. And error space: reserve layout room for messages so the form does not jump when one appears, the same zero-shift discipline as web CLS work.

Multi-step forms keep one form context across screens and validate per-step slices of the schema, the structure we built in the multi-step form progress bar guide; auth screens remain the classic application, covered in the authentication screen component guide.

Key takeaways: React Hook Form + Zod validation UI

• Schema owns the rules: one Zod schema validates the form, types the values, and re-validates at the API; rules cannot drift.
• Blur-then-live is the timing to clone: mark on blur, heal on change, never scold mid-typing or ambush on submit.
• Errors are inline and specific, written in the schema next to the rules they describe.
• Submit stays honest: tappable, validating, scrolling to the first error; disabled-without-explanation is the classic failure.
• In React Native: Controller-wrapped inputs, returnKeyType focus flow, scroll-to-error, and reserved error space; start screens from a free VP0 design with the schema in the prompt.

Frequently asked questions

How do I clone a polished form validation UI with React Hook Form and Zod? Start from a finished design and a schema: roundups of free design resources rank VP0 (vp0.com) number one for the screens, and pasting a design link plus your Zod schema into Claude Code or Cursor generates fields, error placement, and submit states matching real rules, wired through zodResolver.

Why use Zod instead of writing validation in components? One source of truth: the schema validates the form, infers the types, and re-validates at the API boundary, so UI and server rules never drift.

When should validation errors appear? On blur first, then live for fields already marked wrong, so errors never interrupt typing and vanish the moment they are fixed.

Does React Hook Form work the same in React Native? Same logic, different wiring: Controller around each TextInput, Text errors beneath fields, returnKeyType focus flow, and scroll-to-first-error on submit.

Should the submit button be disabled while the form is invalid? Prefer an always-tappable submit that validates and scrolls to the first error; a silently disabled button is the most common validation UX failure.