React Hook Form

Quick Verdict

When to use it: Any React form beyond a single input. Login, registration, settings, multi-step wizards, complex data entry.

When not to: Trivial single-input forms (use useState) or fully server-rendered forms (use Server Actions with native <form>).

Best For

• Performance-sensitive forms — uncontrolled inputs by default; typing in one field doesn't re-render the entire form
• Type-safe validation — Zod resolver gives you schema + TypeScript types from one definition
• Any React form — login, registration, multi-step wizards, settings, admin data entry
• AI-assisted development — useForm + register is a consistent, well-documented pattern

Avoid If

• Trivial single input + button — just use useState
• Fully server-rendered forms without client interactivity — Server Actions with native <form> don't need a library
• You have team members who strongly prefer Formik's render-prop pattern and the forms are simple

Why People Choose It

Formik re-renders the entire form tree on every keystroke — this matters for complex forms. React Hook Form uses uncontrolled components with refs, so form state lives outside React's render cycle. The register pattern connects inputs to the store without triggering re-renders.

The Zod integration is the killer feature. Define a Zod schema, pass it to zodResolver, and you get type-safe form values, automatic validation, and error messages all from one source of truth.

Hidden Costs

Zero. React Hook Form and @hookform/resolvers are free. No subscription, no licensing.

Correct vs Cargo-Culted Patterns

Wrong — Controller for native inputs:

// ❌ Controller is for controlled UI libraries (Select, DatePicker)
<Controller
  name="email"
  control={control}
  render={({ field }) => <input {...field} type="email" />}
/>

Right — register for native inputs:

// ✅ register is faster and simpler for standard HTML inputs
<input {...register('email')} type="email" />

Wrong — watching all fields:

// ❌ Re-renders on every keystroke across all fields
const allValues = watch()

Right — watch specific fields:

// ✅ Only re-renders when 'plan' changes
const selectedPlan = watch('plan')

Wrong — manual validation:

// ❌ Duplicated logic, no type inference
const schema = /* manual validation */
useForm({ validate: (values) => { /* ... */ } })

Right — Zod resolver:

// ✅ One schema, type-safe values, automatic error messages
const schema = z.object({
  email: z.string().email(),
  password: z.string().min(8),
})
const form = useForm<z.infer<typeof schema>>({
  resolver: zodResolver(schema),
})

AI Coding Notes

Always provide your Zod schema as context when generating form code — AI produces dramatically better output when it can see the validation schema. Specify:

• "Use @hookform/resolvers/zod with this schema: [schema]"
• "Use register for native inputs, Controller only for UI library components"
• "Always include formState.errors display"

Common AI Mistakes

1. Controller for everything — more complex and slower than register for standard inputs
2. No resolver — AI generates manual validate functions instead of zodResolver
3. watch() with no selector — subscribes to all fields, triggers re-renders on every keystroke
4. Missing handleSubmit — form submission without handleSubmit wrapper skips validation
5. Not resetting after submission — stale isSubmitted and isDirty create confusing UX after success

Start With / Grow Into / Avoid Until Needed

Start with RHF for any form beyond a trivial single input. The learning curve is low.

Grow into FormProvider + useFormContext for multi-step wizards or forms split across components.

Avoid until needed: useFieldArray for dynamic arrays (only when form allows adding/removing rows), setError for server-side errors (only when you have complex error handling needs).

Migration Implications

Low. Migrating from Formik to RHF means rewriting form components — the validation schemas often transfer (if using Yup/Zod) but the JSX pattern changes. Allow 1–2 hours per form for a straightforward migration.