Forms in React look simple. At scale they're where 80% of the bugs hide — controlled-vs-uncontrolled choices, validation timing, accessibility, error UX, server errors.

The default stack in 2026

react-hook-form  →  form state (uncontrolled, performant)
zod              →  schema (single source of truth)
@hookform/resolvers/zod  →  glue

import { useForm } from "react-hook-form";
import { z } from "zod";
import { zodResolver } from "@hookform/resolvers/zod";

const Schema = z.object({
  email: z.string().email("Enter a valid email"),
  password: z.string().min(8, "At least 8 characters"),
});
type FormValues = z.infer<typeof Schema>;

function SignupForm() {
  const { register, handleSubmit, formState: { errors, isSubmitting } } =
    useForm<FormValues>({ resolver: zodResolver(Schema), mode: "onBlur" });

  async function onSubmit(values: FormValues) {
    try {
      await api.signup(values);
    } catch (e) {
      if (e.code === "EMAIL_TAKEN") {
        setError("email", { message: "Already registered" });
      } else {
        setError("root", { message: "Something went wrong" });
      }
    }
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <label>
        Email
        <input
          {...register("email")}
          aria-invalid={!!errors.email}
          aria-describedby={errors.email ? "email-err" : undefined}
        />
        {errors.email && <p id="email-err" role="alert">{errors.email.message}</p>}
      </label>
      <button disabled={isSubmitting}>Submit</button>
    </form>
  );
}

Why this stack.

• Zod owns types AND validation. No drift between TypeScript and runtime checks.
• RHF uses uncontrolled inputs. No re-render per keystroke. 200-field forms stay fast.
• isSubmitting, errors, isDirty, isValid — comprehensive form state with no plumbing.
• Server-side: the same Zod schema validates the request body. Single source of truth.

Validation timing

Modern UX: mode: "onBlur" for first-pass; switch to "onChange" after isSubmitted. RHF supports this via reValidateMode.

Server errors

The form must accept errors the server returns:

catch (e) {
  if (e.fieldErrors) {
    for (const [field, msg] of Object.entries(e.fieldErrors)) {
      setError(field as keyof FormValues, { message: msg });
    }
  } else {
    setError("root", { message: e.message });
  }
}

Server response shape (typical):

{
  "fieldErrors": { "email": "already in use" },
  "rootError": null
}

Display field errors next to the field; root errors at the top of the form.

Accessibility

The four things that matter:

1. Labels. Every input has a programmatic label — <label> wrapping or htmlFor.
2. Errors associated with inputs. aria-describedby points to the error message.
3. aria-invalid flags invalid fields.
4. Focus the first invalid field on submit failure.

``tsx const { handleSubmit, setFocus } = useForm({ shouldFocusError: true }); ` RHF does this automatically when shouldFocusError` is enabled.

Plus: don't disable the submit button while invalid (it stops keyboard users from triggering the validation feedback). Let them submit and show errors.

Complex patterns

Conditional fields. Use watch() to read other fields, render conditionally; or use the useWatch hook for performance.

Field arrays (useFieldArray) — dynamic list of inputs (tags, attendees). Each row needs a stable key, never index, or removal breaks state.

Multi-step wizards. One useForm per wizard (single source of truth), step components consume slices via Controller or watch.

File uploads. Uncontrolled by nature. RHF stores FileList; convert via onChange. Validate size/type with Zod (z.instanceof(File).refine(...)).

Async validation (username available?). Debounce in the validator; throw on conflict. RHF supports async resolvers.

Drafts / autosave. Watch the form values, debounce, persist to localStorage or to the server. On mount, restore.

Anti-patterns

• Manual useState per field. Tedious; re-renders on every keystroke; no validation framework.
• Validation logic inline in the component. Move to Zod; reuse on server.
• Disabling submit until valid. Keyboard users get stuck without knowing why.
• Error messages only at the top. Field-level + summary, both.
• Trusting client validation for security. Always revalidate server-side.

Senior framing

The interviewer wants:

1. Library choice with rationale (RHF + Zod, not 10 useStates).
2. Single schema for client + server validation.
3. Validation timing thought through (onBlur default).
4. Accessibility (labels, errors, focus management).
5. Server-side error integration.
6. Performance posture (RHF's uncontrolled approach for large forms).
7. Acknowledgment that the server is the security boundary, not the form.

The "I use useState and validate in onSubmit" answer is junior. The stack + considerations above is senior.