Coder Legion - Recent posts tagged zod

Zod vs Yup in 2026: Which Validation Library Should You Use?

Sat, 22 Aug 2026 04:00:34 +0000

You've got a signup form. Email, password, maybe a checkbox for terms and conditions. Simple, right? Then someone submits email: 123 and your API route crashes with a cryptic error three files deep, because nothing ever checked that the data coming in actually matched what your code expected.

That's the exact gap schema validation libraries fill — and if you've searched for one, you've almost certainly landed on two names: Zod and Yup. Both let you describe the shape of your data once and validate real values against it. Both work great with React Hook Form. Both have been around long enough to be genuinely production-tested.

But they're not interchangeable, and picking the wrong one for your setup means either fighting TypeScript for months or hand-writing types you shouldn't have to. By the end of this guide, you'll know exactly how Zod and Yup differ, see real code for both, and know which one actually fits your project — not just which one has more GitHub stars.

Quick Answer

Choose Zod if you're using TypeScript and want your schema to be your type — no writing an interface separately and hoping it stays in sync.
Choose Yup if you're maintaining an existing Formik-based codebase, or your team is more comfortable with its .shape() API and mature async validation methods.

For any brand-new TypeScript project in 2026, Zod is the safer long-term default — it's what most modern tools (React Hook Form, tRPC, Next.js Server Action patterns) assume you're using. Now let's get into why.

What Is Schema Validation, Exactly?

Before comparing the two, a quick beginner-friendly definition: a schema is just a description of what your data should look like — "this field is a string," "this field is a number between 1 and 100," "this field is a valid email." A validation library takes that schema and checks real, incoming data (a form submission, an API request body) against it, telling you exactly what's wrong if it doesn't match.

Without one, you end up writing manual checks like this everywhere:

if (typeof data.email !== "string" || !data.email.includes("@")) {
  throw new Error("Invalid email");
}

Multiply that across every field, every form, every API route, and it gets messy fast — inconsistent error messages, duplicated logic, and no single source of truth for what "valid" even means. Zod and Yup both solve this by letting you define the rules once and reuse them everywhere.

Zod: TypeScript-First Validation

Zod was built specifically for TypeScript projects. Its core idea: you write one schema, and Zod derives both the runtime validator and the TypeScript type from it — there's no second place to keep in sync.

Installing Zod

npm install zod

A Basic Zod Schema

// lib/validators/user-schema.ts
import { z } from "zod";

export const userSchema = z.object({
  name: z.string().min(2, "Name must be at least 2 characters"),
  email: z.email("Please enter a valid email address"),
  age: z.number().int().positive().optional(),
  website: z.url().optional(),
});

// The type is derived directly from the schema — never written twice
export type User = z.infer<typeof userSchema>;

What's happening here: z.object({...}) describes the shape. z.email() and z.url() are Zod's built-in format validators (as of Zod v4, these live as top-level helpers rather than chained .email() string methods, though the chained form still works). z.infer<typeof userSchema> pulls a real TypeScript type straight out of the schema — if you add a field to the schema, the User type updates automatically, with zero manual work.

💡 Tip: This is Zod's single biggest selling point. You will never end up with a TypeScript interface that's quietly out of sync with your actual validation rules, because there's only one definition.

Validating Data with Zod

// Somewhere handling a form submission or API request
const result = userSchema.safeParse({
  name: "Ali",
  email: "not-an-email",
});

if (!result.success) {
  console.log(result.error.flatten().fieldErrors);
  // { email: ["Please enter a valid email address"] }
} else {
  // result.data is fully typed as `User`
  console.log(result.data.name);
}

What's happening here: safeParse() never throws — it returns a { success: true, data } or { success: false, error } object, so you don't need a try/catch block for normal validation flow. error.flatten().fieldErrors gives you a clean, per-field map of error messages, perfect for showing next to form inputs.

⚠️ Common Mistake: Using .parse() instead of .safeParse() in a code path where invalid data is expected (like a form submission). .parse() throws on failure, which means you need a try/catch everywhere — .safeParse() is almost always the better default for user input.

Zod in a Next.js Server Action

// actions/create-user.ts
"use server";

import { userSchema } from "@/lib/validators/user-schema";

export async function createUser(prevState: unknown, formData: FormData) {
  const result = userSchema.safeParse({
    name: formData.get("name"),
    email: formData.get("email"),
  });

  if (!result.success) {
    return { errors: result.error.flatten().fieldErrors };
  }

  // result.data is typed and safe to use here
  // await db.user.create({ data: result.data });

  return { success: true };
}

This is the exact pattern you'll see across most modern Next.js codebases — validate raw FormData on the server, never trust the client, and let the schema do the type narrowing for you.

Yup: The Established Forms Favorite

Yup predates the current TypeScript-first wave of tooling. It grew up alongside Formik and is still deeply embedded in a lot of React form codebases, particularly ones started before 2022.

Installing Yup

npm install yup

A Basic Yup Schema

// lib/validators/user-schema.ts
import * as yup from "yup";

export const userSchema = yup.object({
  name: yup.string().min(2, "Name must be at least 2 characters").required(),
  email: yup.string().email("Please enter a valid email address").required(),
  age: yup.number().integer().positive(),
  website: yup.string().url(),
});

// Yup's type inference — functional, but less precise than Zod's
export type User = yup.InferType<typeof userSchema>;

What's happening here: the shape looks similar to Zod at a glance, but notice .required() — in Yup, fields are optional by default unless you explicitly mark them required, which is the opposite of Zod's default (Zod fields are required unless you call .optional()). This trips up a lot of developers switching between the two.

⚠️ Common Mistake: Forgetting .required() on a Yup field and assuming it behaves like Zod. Yup schemas silently allow undefined on any field you don't explicitly mark required — this is one of the most common Yup-related bugs in production forms.

Validating Data with Yup

try {
  const validData = await userSchema.validate(
    { name: "Ali", email: "not-an-email" },
    { abortEarly: false }
  );
  console.log(validData);
} catch (err) {
  if (err instanceof yup.ValidationError) {
    console.log(err.errors); // ["Please enter a valid email address"]
  }
}

What's happening here: Yup's .validate() is async by default and returns a Promise — this is a real difference from Zod, where safeParse is synchronous unless you specifically opt into safeParseAsync. abortEarly: false tells Yup to collect every validation error instead of stopping at the first one. For a version that never throws, Yup also offers validateSync() with a try/catch, or you can check .isValid().

Yup in a Next.js Server Action

// actions/create-user.ts
"use server";

import { userSchema } from "@/lib/validators/user-schema";
import { ValidationError } from "yup";

export async function createUser(prevState: unknown, formData: FormData) {
  try {
    const data = await userSchema.validate(
      {
        name: formData.get("name"),
        email: formData.get("email"),
      },
      { abortEarly: false }
    );

    // await db.user.create({ data });
    return { success: true };
  } catch (err) {
    if (err instanceof ValidationError) {
      const fieldErrors: Record<string, string[]> = {};
      for (const e of err.inner) {
        if (e.path) fieldErrors[e.path] = [...(fieldErrors[e.path] ?? []), e.message];
      }
      return { errors: fieldErrors };
    }
    throw err;
  }
}

Notice this requires a try/catch and manually reshaping err.inner into a field-keyed object — Zod's flatten().fieldErrors gives you that shape for free.

Zod vs Yup: Side-by-Side

	Zod	Yup
TypeScript inference	Automatic, precise (`z.infer`)	Functional but looser (`InferType`)
Default field behavior	Required by default	Optional by default
Validation style	Sync by default (`safeParse`), async available	Async by default (`.validate()`)
Error shape	Structured `ZodError` with `.flatten()`	`ValidationError` with `.inner` array
Bundle size (gzipped)	Zod is slightly larger, but the difference <br/> is usually too small to matter for real <br/> applications.	Slightly smaller
React Hook Form support	✅ via `@hookform/resolvers/zod`	✅ via `@hookform/resolvers/yup`
Ecosystem fit	tRPC, modern Next.js patterns, Server Actions	Formik, legacy React form codebases
Learning curve	Slightly more API surface	Simpler, more forgiving for JS-first teams
Best for	New TypeScript projects	Existing Formik/Yup codebases

💡 Tip: Bundle size differences here are small enough that they shouldn't be your deciding factor for most apps — a few KB gzipped rarely matters next to your actual app code and images.

Using Either One with React Hook Form

This is where a lot of real-world decisions actually get made, so it's worth showing both side by side. Both integrate through the same @hookform/resolvers package.

npm install react-hook-form @hookform/resolvers

With Zod:

"use client";

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

const formSchema = z.object({
  email: z.email(),
  password: z.string().min(8, "Password must be at least 8 characters"),
});

type FormValues = z.infer<typeof formSchema>;

export function LoginForm() {
  const { register, handleSubmit, formState: { errors } } = useForm<FormValues>({
    resolver: zodResolver(formSchema),
  });

  const onSubmit = (data: FormValues) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("email")} />
      {errors.email && <p>{errors.email.message}</p>}

      <input type="password" {...register("password")} />
      {errors.password && <p>{errors.password.message}</p>}

      <button type="submit">Log in</button>
    </form>
  );
}

With Yup:

"use client";

import { useForm } from "react-hook-form";
import { yupResolver } from "@hookform/resolvers/yup";
import * as yup from "yup";

const formSchema = yup.object({
  email: yup.string().email().required(),
  password: yup.string().min(8, "Password must be at least 8 characters").required(),
});

type FormValues = yup.InferType<typeof formSchema>;

export function LoginForm() {
  const { register, handleSubmit, formState: { errors } } = useForm<FormValues>({
    resolver: yupResolver(formSchema),
  });

  const onSubmit = (data: FormValues) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("email")} />
      {errors.email && <p>{errors.email.message}</p>}

      <input type="password" {...register("password")} />
      {errors.password && <p>{errors.password.message}</p>}

      <button type="submit">Log in</button>
    </form>
  );
}

What's different: almost nothing at the React Hook Form layer — swap the resolver, swap the schema syntax, and everything else stays identical. This is exactly why the "which one" decision usually comes down to TypeScript ergonomics and team familiarity rather than form-library compatibility, since both are equally well supported.

Async Validation: Where Yup Still Has an Edge

If you need to check something against a server mid-validation — "is this username already taken?" — Yup's .test() method has had mature async support for years:

const signupSchema = yup.object({
  username: yup.string().test(
    "unique-username",
    "This username is already taken",
    async (value) => {
      if (!value) return true;
      const res = await fetch(`/api/check-username?u=${value}`);
      const { available } = await res.json();
      return available;
    }
  ),
});

Zod supports async refinements too, using .refine() with an async function and safeParseAsync():

const signupSchema = z.object({
  username: z.string(),
}).refine(
  async (data) => {
    const res = await fetch(`/api/check-username?u=${data.username}`);
    const { available } = await res.json();
    return available;
  },
  { message: "This username is already taken", path: ["username"] }
);

// must use safeParseAsync, not safeParse, when the schema has async refinements
const result = await signupSchema.safeParseAsync({ username: "ali" });

What's happening here: both libraries can do this — Yup's API was simply designed around async validation from the start, so it reads slightly more naturally. Zod requires you to remember to swap safeParse for safeParseAsync whenever an async .refine() is in play, which is an easy thing to forget.

⚠️ Common Mistake: Calling safeParse() (not safeParseAsync()) on a Zod schema with an async .refine(). It won't throw — it'll just resolve the refinement incorrectly, since Zod can't await inside a synchronous parse. Always match safeParseAsync to async refinements.

Migrating from Yup to Zod (If You're Considering It)

If you're weighing a migration, here's the honest advice: don't rewrite a working Yup codebase just to switch libraries. The type-safety gains are real, but they're not worth the regression risk on schemas that already work in production. Reach for Zod on new features or new projects instead, and let old Yup schemas retire naturally as you touch that code for other reasons.

If you are migrating a specific schema, the field-by-field mapping is usually mechanical:

Yup	Zod
`yup.string().required()`	`z.string()`
`yup.string().optional()`	`z.string().optional()`
`yup.string().email()`	`z.email()`
`yup.number().integer()`	`z.number().int()`
`yup.object().shape({...})`	`z.object({...})`
`yup.InferType<typeof schema>`	`z.infer<typeof schema>`

Frequently Asked Questions

Can I use Zod without TypeScript?

Yes, Zod works fine in plain JavaScript — but you lose its single biggest advantage, since type inference only matters if you have TypeScript to infer into. If your project is JavaScript-only, Zod and Yup are much closer in practical value, and team familiarity should decide it.

Is Zod always faster than Yup?

Not necessarily, and it depends heavily on the shape of your schema. For most typical form-sized payloads, both validate in well under a millisecond, so raw performance differences almost never matter in practice — TypeScript ergonomics and API fit are the more meaningful factors.

Do I need to rewrite my Formik forms to use Zod?

No. Formik and Yup are still a perfectly fine, actively maintained combination for existing codebases. Only reach for a migration if you're already refactoring that form layer for other reasons.

Which one works better with tRPC?

Zod, by a wide margin — tRPC's input/output validation is built with Zod's type inference in mind, and most tRPC examples and starter templates assume Zod. Yup can technically be adapted, but it's fighting the grain.

Can I use both Zod and Yup in the same project?

Technically yes, but it's not something to do on purpose. If you're migrating incrementally, it's fine to have both installed temporarily — just avoid mixing them within the same feature or form, since their default behaviors (required vs. optional fields, sync vs. async) differ enough to cause confusing bugs.

Does Zod support transforming data, not just validating it?

Yes — .transform() lets you reshape data as part of validation, like converting a string date into a Date object. Yup supports this too, through .transform() on its schemas. Both are equally capable here.

Wrapping Up

Zod and Yup solve the exact same problem — turning "hope the data is right" into "know the data is right" — but they were built for different eras of the JavaScript ecosystem. Zod's schema-is-the-type approach is what modern TypeScript tooling expects in 2026, and it's the right default for anything new you're building. Yup remains a completely legitimate choice if you're maintaining an existing Formik-based app, and there's no urgency to rip it out just because a newer library exists.

If you're starting a project today: reach for Zod, pair it with @hookform/resolvers/zod for your forms, and use .safeParse() on the server inside every Server Action or API route that touches user input — never trust that client-side validation alone is enough.

Try This Free Developer Tool

Zod Schema Generator — paste a JSON sample or a TypeScript interface and get a production-ready Zod schema instantly, complete with smart field-name inference, a live validator, and ready-to-use React Hook Form, API Route, and Server Action output.

Continue Learning

Building Type-Safe AI Prompts with TypeScript

Tue, 21 Jul 2026 09:58:49 +0000

Building Type-Safe AI Prompts with TypeScript

In the previous article, we explored why prompt strings become difficult to manage as AI applications grow.

But identifying the problem is only half the journey.

The next question is:

How should we build prompts instead?

As developers, we already have great tools for building reliable software.

TypeScript catches type errors.
Zod validates runtime data.
ESLint catches mistakes before production.
Unit tests prevent regressions.

So why are prompts still written as plain strings?

Today we'll explore how type-safe prompt engineering makes AI applications more reliable and easier to maintain.

Traditional Prompt Engineering

Most applications still look something like this.

const prompt = `
You are an expert technical writer.

Summarize the following article.

Language: ${language}

Tone: ${tone}

Article:

${article}
`;

Looks simple.

But what happens if someone writes

generatePrompt({
  language: "English"
});

Oops.

They forgot

article

TypeScript doesn't complain.

Your IDE doesn't complain.

The application compiles successfully.

You only discover the issue after making an expensive API request.

The Problem Isn't AI

The problem is that strings don't describe structure.

Consider this prompt.

`
Summarize

${text}

Audience

${audience}

Output

${format}
`

Questions immediately arise.

Is text required?
Can audience be empty?
What values are allowed?
What format should the output follow?

The string itself can't answer any of these questions.

Introducing Structure

Instead of describing prompts as text...

Describe them as objects.

const summarize = pf.define({

  input: z.object({

    article: z.string(),

    audience: z.enum([
      "developer",
      "student",
      "executive"
    ])

  }),

  output: z.object({

    summary: z.string()

  }),

  messages: ({ article, audience }) => [

    pf.system`
      You are an expert writer.

      Tailor explanations for a ${audience}.
    `,

    pf.user`
      Summarize:

      ${article}
    `

  ]

});

Now your prompt has an actual API.

Type Inference for Free

One of my favorite parts of TypeScript is that you rarely need to write interfaces manually.

The same idea applies here.

type Input = pf.inferInput<typeof summarize>;

Immediately becomes

{
  article: string;
  audience: "developer" | "student" | "executive";
}

No duplicated types.

No maintenance.

Everything stays synchronized automatically.

Runtime Validation

TypeScript only protects you during development.

What happens when data comes from an API?

Or a form?

Or user input?

That's where runtime validation matters.

summarize.compile({

  article: 42,

  audience: "developer"

});

Instead of silently failing later...

PromptForge immediately throws

PromptValidationError

Expected

article: string

Received

number

You catch mistakes before calling the LLM.

Strongly Typed Outputs

Inputs aren't the only thing that benefit from schemas.

Outputs do too.

output: z.object({

  title: z.string(),

  summary: z.string(),

  keywords: z.array(z.string())

})

Now your application knows exactly what shape the response should have.

This opens the door to

Structured Outputs
Tool Calling
JSON validation
Better autocomplete
Safer parsing

Reusable Prompt Components

Most AI applications repeat instructions.

Instead of copying them...

Create reusable blocks.

const safety = pf.define({

  messages: () => [

    pf.system`
      Never expose secrets.
    `

  ]

});

Then compose them.

const assistant = pf.define({

  input: z.object({

    question: z.string()

  }),

  messages: ({ question }) => [

    pf.include(safety),

    pf.user`${question}`

  ]

});

No duplicated strings.

No copy-paste.

Better Developer Experience

Because PromptForge understands your schema...

Your editor can help you.

When typing

assistant.compile({

VS Code immediately suggests

question

Autocomplete.

Hover information.

Type checking.

Everything developers already expect from modern tooling.

Why This Matters

Large AI applications eventually become collections of prompts.

Those prompts deserve the same engineering principles as the rest of your codebase.

Modular
Reusable
Type-safe
Testable
Validated

Treating prompts like software makes them dramatically easier to maintain.

Looking Ahead

Type safety is only the beginning.

In the next article, we'll explore one of the most powerful ideas behind PromptForge:

Composable Prompt Engineering

Instead of copying prompts across your project, we'll build reusable prompt blocks that can be combined just like React components.

Once you start composing prompts, you'll never want to go back to copy-pasting instructions.

Installation

npm install @promptforgee/core

Resources

Documentation

https://prompt-forge-docs.vercel.app/

⭐ GitHub

https://github.com/Omnikon-Org/PromptForge

npm

https://www.npmjs.com/package/@promptforgee/core

Final Thoughts

Prompt engineering is quickly becoming an essential part of modern software development.

The better our applications become, the more valuable our prompts become.

So maybe it's time we stop treating prompts like strings...

...and start treating them like software.

If you're building AI applications with TypeScript, I'd love to hear your thoughts.

How are you currently managing prompts in your projects?

I got tired of faker mocks silently breaking my tests, so I built zodmint

Mon, 25 May 2026 22:44:32 +0000

You know the pattern: you write a factory with faker, tests pass locally, then CI blows up because faker.number.int() generated a negative value that fails your .positive() constraint. The mock was lying the whole time.

I built zodmint to fix this. You pass a Zod schema in, you get a valid value out, guaranteed to pass schema.safeParse(output).success === true. No faker, no hand-written factories.

npm install zodmint

Basic usage:

const UserSchema = z.object({
  id: z.uuid(),
  email: z.string().email(),
  age: z.number().int().min(18).max(99),
  role: z.enum(["admin", "user", "guest"]),
});

mock(UserSchema);
// { id: 'b48653da-...', email: '*Emails are not allowed*', age: 41, role: 'admin' }

It also has:

mockFactory() with named states, afterBuild hook, and extend()
Seeded generation (same seed = same output, great for snapshots)
Edge mode (boundary values for stress testing)
Custom matchers and a plugin system for domain-specific values
Full support for z.union, z.discriminatedUnion, z.intersection, z.lazy, z.refine, and more

Got some downloads in the first 24h without posting anywhere which surprised me. Would love feedback from people actually using it.

npm: https://www.npmjs.com/package/zodmint
GitHub: https://github.com/gonll/zodmint

Get Started with React Hook Form

Mon, 17 Nov 2025 11:22:30 +0000

Introduction

Hi, guys!

Recently, I spent some time improving my React skills. And the feeling that I will never know enough never goes away, but that is another talk. Just know it is perfectly normal to feel this way.

This is how I found out about React Hook Form. Ok, actually, it wasn't first time I heard about it, but now I just decided to learn more about it. So I just read their docs a little bit and decided I will share the knowledge with you.

I won't dive too deep into the subject. The goal is to get as familiar as possible with this library.

So let's get started!

What is React Hook Form and Why Should You Use It?

It is a light library that helps you manage forms easily in React.

What it offers:

Light

Provides an intuitive experience, with rich features, all of these while staying light and not relying on other dependencies.

Performance

It reduces the amount of code, it reduces the number of re-renders, due to its use of uncontrolled components by default and offers faster mounting and reduced validation computations. Because the form components don't update the state with every keystroke, the components and its children don't re-render.

Validations

React Hook Form leverages existing HTML markup and makes form validation easy.

Error Handling

It provides an errors object which you can use to retrieve errors.

Loading State

Methods like isSubmitting, isLoading, isValidating makes managing loading state more intuitive.

Installation and Basic Usage

React Hook Form is easy to setup. Start by using the following command in your terminal:

npm install react-hook-form

Imagine how you do it normally without React Hook Form:

import { useState } from 'react';

const Form = () => {
  const [ name, setName ] = useState('');

  return (
    <form>
      <input onChange={() => setName(e.target.value)} value={name} />
    </form>
  );
};

This is fine, right? It is a very small form, won't create any problems, hopefully. But what if it scales? What if instead of one input you get 10? Imagine you have to manage that huge form state, together with loading and error handling. And think about performance and the amount of code written. The number of re-renders will be huge, maybe the app will be sluggish.

And this is how it comes to the rescue. Let's demonstrate some basic usage:

import { useForm } from "react-hook-form";

export default function App() {
  const { register, handleSubmit } = useForm();
  const onSubmit = (data) => console.log(data);

  return (
    /* "handleSubmit" will validate inputs before invoking "onSubmit" */
    <form onSubmit={handleSubmit(onSubmit)}>
     {/* register your input into the hook by invoking the "register" function */}
     <input {...register("example")} />
     <input type="submit" />
    </form>
  );
}

When you call useForm(), the function returns a number of useful functions. We will talk about some of them in the next sections, but two of the most important ones are register and handleSubmit.

register function, as the name implies, will register your input into the hook and will apply validation rules to it. What does it mean? It means you now don't need useState and onChange and value to manage your input state. It is managed by React Hook Form, but leveraging uncontrolled components.

When you actually use it inside an input, the syntax is this:

<input {...register("name"), validations} />

It accepts two parameters. The first one will be a string and it's going to be a name of your choosing. Keep in mind that this is like applying a name attribute on a HTML tag and you are going to use this name with other useForm() functions as well. The second attribute is an object with validations, which we'll discuss in the next section. So you could have something like this:

import { useForm } from "react-hook-form";

export default function App() {
  const { register, handleSubmit } = useForm();
  const onSubmit = (data) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
     <input {...register("firstName", { reguired: true, maxLength: 20 })} />
     <input type="submit" />
    </form>
  );
}

handleSubmit will receive your form data only if input validation ended successfuly. It accepts two callbacks, one for success and one for errors.

import { useForm } from "react-hook-form";

export default function App() {
  const { register, handleSubmit } = useForm();
  const onSubmit = (data) => console.log(data);
  const onError = (errors) => console.log(errors);

  return (
    <form onSubmit={handleSubmit(onSubmit, onError)}>
      <input {...register("firstName")} />
      <input {...register("lastName")} />
      <input type="email" {...register("email")} />
      <input type="submit" />
    </form>
  );
}

Validations, Error Handling and Loading

React Hook Form aligns with HTML standard for form validations. This means it supports rules like:

required
min
max
minLength
maxLength
pattern
validate

Let's see how it works:

import { useForm } from "react-hook-form";

export default function App() {
  const { register, handleSubmit } = useForm();
  const onSubmit = (data) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
     <input {...register("firstName", { reguired: true, maxLength: 20, minLength: 1 })} />
     <input type="number" {...register("age", { required: true, min: 18, max: 99 })} />
     <input type="number" {...register("experience"), { pattern: /\d/ }}
     <input type="number" {...register("lastName"), {
       validate: { (lastName) => if (!lastName) => 'Last name is required' }
     }} 
     <input type="submit" />
    </form>
  );
}

While some of them are naturally logical and intuitive, the validate rule asks for some explanations. It is an object where you can insert as many validation methods (functions) as you need. For example:

register('fieldName', {
  validate: {
    // 1. First Validation Function
    mustBeAdult: (value) => value >= 18 || "Must be 18 or older",
    // 2. Second Validation Function
    isEvenNumber: (value) => value % 2 === 0 || "Must be an even number",
    // 3. Third Validation Function
    notZero: (value) => value !== 0 || "Cannot be zero",
  },
});

How does error handling work with validate rule? The validation functions run in the order they are defined and if a validation function returns true, validation passes for that rule.

If a function returns a string like "Must be 18 or older", that string is treated as the error message, and validation stops for that field immediately and will display the error message from the first function that fails.

There are other rules for validations inside register function as well. Read more about them here.

To handle errors in React Hook Form is easy. You first have to destructure the useForm() hook and get the formState, which you will then destructure to get errors:

import { useForm } from 'react-hook-form';

const Form = () => {
  const { register, handleSubmit, formState: {errors} } = useForm();

 return (
    <form onSubmit={handleSubmit(onSubmit)}>
     <input {...register("firstName", { reguired: 'Name required', maxLength: { value: 20, message: 'No more than 20' }} )} />
     {errors.firstName.message && <p>{errors}</p>}
     <input type="number" {...register("age", { required: true, min: { value: 18, message: 'At least 18' }, max: 99 })} />
     {errors.age.message && <p>{errors}</p>}
     <input type="submit" />
    </form>
  );
}

The syntax for writing errors is something like this:

{...register("age", { required: true, min: { value: 18, message: 'At least 18' }})}

And instead of required: true, you can also give this property a string value, which will act as an error message. Now if the field is not filled you will see 'Name required' under it. Notice that when you register your input, the errors object will get a key that will match the name you registered the input with. And that key will be an object which will hold the 'message' property. That is how you can smartly access the errors for every field. No headache required. So in our case:

  errors.firstName.message
  errors.age.message

The formState also holds other useful properties. Check them all here. We'll also discuss here some of them that are related to loading state: isSubmitting, isLoading, isValidating.

All of these three are booleans. And you guessed right, isSubmitting is true during the time the form is submitting. You might use it when you want to disable a submit button during form submission. isLoading only works with default async values and it is true when the form is loading these values. Example:

const { formState: { isLoading, isSubmitting } } = useForm({
  defaultValues: async () => await fetch('/api');
})

We didn't say anything about default values in useForm as props yet. But it is easy to understand. It's like using defaultValue in React. However, as the documentation recommends:

The defaultValues prop populates the entire form with default values. It supports both synchronous and asynchronous assignment of default values. While you can set an input's default value using defaultValue or defaultChecked (as detailed in the official React documentation), it is recommended to use defaultValues for the entire form.

So you will use isLoading if you have default values that are async, in other words, if those values, that you want as defaults for your inputs, take time until they are loaded into your form.

The last one, isValidating is going to be true during validation, otherwise false. Example for all:

import { useForm } from "react-hook-form";
import { useState } from 'react';

export default function App() {
  const [ value, setValue ] = useState();
  const { register, handleSubmit, formState: {errors, isSubmitting, isLoading, isValidating},
  } = useForm({
    defaultValues: async () => await someValue().then((value) => setValue(value)); 
  });
  const onSubmit = (data) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
       {isValidating? <p>Validating your form...</p> : <p>Validated successfuly!</p>}
      {isLoading? <p>The value is loading</p> : <p>{value}</p>}
      <input {...register("test")} />
      <button disabled={isSubmitting? true : false}>{isSubmitting? 'Submitting...' : 'Submit'}</button>
    </form>
  );
}

UseForm Functions and Props

When you call useForm(), you make available a useful set of properties and methods. Some of them we already discussed, like register, formState, handleSubmit. Some others are unregister, setErrors, watch, setValue, reset, setFocus. And there are other more.

Note that all these returned functions from useForm have some other options as their second parameters. Chech the documentation for more information.

Now let's say a thing or two about these form above for now, just to get the hang of it.

You will want to use unregister when you need to programmatically remove a field's data and validation rules from the form state. Imagine you have some fields in your app that are conditionally rendered. Imagine a field that is not rendered if a checkbox is not checked, being conditionally rendered. Without unregistering this field, even if the field is not there visually, it exists as state and validation. When you submit the form, the form is also submitted with data from this field, that you didn't even use. You can expect some problems in your app if you don't unregister.

You can do this programatically using useEffect. This is a cleanup that will run whenever the component will unmount. So this how you remove the field's state and data.

const { unregister } = useForm();

useEffect(() => {
  return () => {
    unregister("fieldName");
  };
}, [unregister]);

However, there is another approach, a more modern one, that implies enabling automatic unregistration:

Just like using defaultValues prop, this is another prop in useForm that clean up the field state when the component unmounts and makes your code much cleaner. Note that this is false by default.

const methods = useForm({
  // Set this option to true
  shouldUnregister: true, 
});

The setErrors and setValue are both valuable when you need to programatically set other errors that are maybe not validation related, such as network errors or so and when you want to set a value, when clicking a button, for example.

const { unregister } = useForm();

// pretend it's a network error
if (networkError) {
  setError('name of the field', { type: string, message: 'Network error'});
}

// pretend you clicked a button to change an input value 
if (buttonClicked) {
  setValue('name of the field', value);
}

The reset function allows you to reset the whole form state. It accepts options which allow for partial reset. setFocus allow to set focus on a field programatically. It accept a string value, which is going to be the name of the field you want to focus on and some options as an object.

The watch function lets you subscribe to input changes. Keep in mind that this will activate re-rendering. You can watch a sinlge field, multiple fields of your choice or the entire form.

// single field
const form = watch();

// multiple fields
const names = watch([ 'firstName', 'lastName' ]);

// entire form
const name = watch("name");

The useForm() accepts props. We have already seen some of them earlier, like defaultValues, shouldUnsubscribe. But there are many others: disabled, errors, values. And also there some specific ones that are related to validation libraries, like zod and yup, which are called resolvers. You can read more about them here.

Implementation with Zod + TypeScript

We have seen that React Hook Form also accepts validations by default. If you want to go even further, you can make use of Zod and TypeScript. These are modern ways of validating user inputs and make your app more robust.

You can create a Zod schema and apply it to the hook. This is how:
First you have to install the resolvers.

npm i @hookform/resolvers

Then you import it, create the schema and use it in the props of useForm() hook;

import { zodResolver } from '@hookform/resolvers/zod;

interface schema {
  firstName: string,
  lastName: string
}

const { register, handleSubmit } = useForm<schema>({
  resolver: zodResolver(schema)
});

This will validate your input against the schema and return with either errors or a valid result.

React Hook Form doesn't only support Zod. It also supports schema-based form validation with Yup, Superstruct or Joi.

Conclusion

I hope I made React Form Hook at least a bit more easier to start with. Now you've got the basics down... Next step is to go a little deeper according to your needs.

Check out the official documentation

As for more mature developers, what do you think about React Hook Form?

Connect with me

I am open for work, for collaborations, for freelancing or just tech related discussions.

So for anything, just let me know, leave me a message and I'll get in touch as soon as possible!

Follow me and see my work on Github: alexandru-ene-dev
Let's be friends on: LinkedIn: alexandru-ene-dev
Let's chat on Discord: alexandru.ene.dev
Find me also on Dev.to: alexandru-ene-dev

Please, do tell me if you have any sugestions for new content or how to improve it. Your feedback is important to me!

Thank you so much for reading and I will see you in the next one soon! Happy coding! :)