Difficulty: Intermediate
What are the advantages of React Hook Form over controlled form state? How do you integrate validation?
Let's talk about React Hook Form, because if you've ever built a form with more than three fields using manual useState for every single input, you've probably felt the pain that this library solves.
Here's the core problem. In the traditional React approach to forms, you create a piece of state for every input -- const [email, setEmail] = useState(''), const [password, setPassword] = useState(''), and so on. Every keystroke triggers a setState call, which triggers a re-render of the entire form component. For a login form with two fields, this is fine. For a registration form with 10 fields, it's still manageable. But for a complex form with 50 or 100 fields -- think admin dashboards, data entry screens, or multi-step wizards -- those re-renders on every single keystroke start adding up and the UI can feel sluggish.
React Hook Form (RHF) takes a fundamentally different approach. Instead of controlling every input with React state (controlled inputs), it uses uncontrolled inputs by default. When you call register('email'), RHF attaches a ref to that input and reads its value directly from the DOM when needed. No state update on every keystroke means no re-render on every keystroke. The form only re-renders when it actually needs to -- on submission, on validation, or when you explicitly watch a field.
The API is beautifully simple. You call useForm() to get the form utilities. register('fieldName') gives you the props to spread onto an input -- it handles name, ref, onChange, and onBlur. handleSubmit wraps your submission function and prevents the default form submission, runs validation, and passes you the clean data. formState gives you errors, isSubmitting, isValid, isDirty, and other useful flags.
Now, validation. RHF has built-in validation rules -- you can pass required, min, max, minLength, maxLength, pattern, and custom validate functions directly to register. But for real-world apps, you'll almost certainly want schema-based validation with Zod. Here's why: with Zod, you define your validation schema once, and you get TypeScript types inferred from it automatically via z.infer<typeof schema>. Your form data type and your validation rules are a single source of truth. No more keeping a TypeScript interface and validation rules in sync manually.
The integration works through @hookform/resolvers -- you pass zodResolver(schema) as the resolver option to useForm, and RHF delegates all validation to Zod. Errors come back with the exact messages you defined in your Zod schema, properly typed and mapped to field names.
The mode option controls when validation runs. 'onSubmit' (default) only validates when the form is submitted. 'onBlur' validates each field when the user leaves it -- this is usually the best user experience because the user gets immediate feedback without being interrupted while typing. 'onChange' validates on every keystroke, which can feel aggressive but is useful for things like password strength meters. 'all' runs both onBlur and onChange.
There's one important detail: the Controller component. RHF's register function works with native HTML inputs (input, select, textarea) because those support refs. But third-party UI components like a custom DatePicker, a styled Select dropdown from a component library, or a rich text editor often don't expose refs. For those, you wrap them in Controller, which bridges RHF's uncontrolled model with the component's controlled API.
The watch function is worth mentioning because it's a common source of confusion. It lets you subscribe to a field's value and re-render when it changes -- useful for conditional fields (show field B when field A has a certain value). But because it causes re-renders, you should use it sparingly. If you just need the value on submission, you don't need watch.
A quick word about Formik, the other popular form library. Formik uses controlled inputs under the hood, which means it re-renders on every keystroke by default. For most forms this is fine, but RHF's uncontrolled approach gives it a meaningful performance edge on large forms. Formik is still a perfectly valid choice for simpler forms, but the React ecosystem has been trending toward RHF.
In production, my advice is: if you have more than two or three fields, reach for React Hook Form. The performance benefit, the clean API, and the Zod integration make it worth the small learning curve. It's become the de facto standard for forms in modern React applications.
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';
const schema = z.object({
email: z.string().email('Invalid email'),
password: z.string().min(8, 'At least 8 characters'),
age: z.number({ invalid_type_error: 'Age must be a number' }).min(18)
});
type FormData = z.infer<typeof schema>;
function LoginForm() {
const {
register,
handleSubmit,
formState: { errors, isSubmitting, isValid },
reset,
watch
} = useForm<FormData>({
resolver: zodResolver(schema),
mode: 'onBlur' // Validate on blur
});
const onSubmit = async (data: FormData) => {
await loginUser(data);
reset();
};
return (
<form onSubmit={handleSubmit(onSubmit)} noValidate>
<input {...register('email')} type="email" />
{errors.email && <p>{errors.email.message}</p>}
<input {...register('password')} type="password" />
{errors.password && <p>{errors.password.message}</p>}
<button type="submit" disabled={isSubmitting}>
{isSubmitting ? 'Logging in...' : 'Login'}
</button>
</form>
);
}zodResolver bridges Zod schema validation to RHF. register() injects name, ref, onChange, onBlur. Errors are typed from the Zod schema.
React Hook Form, Zod, Validation, Uncontrolled Forms, Performance