DEV Community: Karthik Reddy

The Evolution of Web Forms — Final Part

Karthik Reddy — Mon, 24 Aug 2026 06:48:14 +0000

The Evolution of Web Forms — Final Part: Enterprise Architecture and the Future of Forms

In the previous parts, we followed the evolution of forms through several generations:

Plain HTML forms
        ↓
Native HTML validation
        ↓
Vanilla JavaScript validation
        ↓
AJAX submission
        ↓
Controlled React forms
        ↓
Form-management libraries
        ↓
React Hook Form
        ↓
Zod schemas
        ↓
Backend validation
        ↓
Accessible and performant forms

At this point, we know how to build a reliable registration form.

However, many production forms are not simple registration forms.

Real applications contain:

Multi-step onboarding
Dynamic work-experience sections
Conditional fields
Nested objects
File uploads
Draft saving
Autosave
Asynchronous validation
Optimistic updates
Server-side actions
AI-assisted input
OCR document processing
Voice-based data entry

The final part of this series covers:

Enterprise forms
Modern production architecture
The future of web forms

Stage 17: Enterprise Forms

An enterprise form is not defined only by its number of fields.

A form becomes complex when it must coordinate:

Many values
Multiple workflow steps
Conditional rules
Dynamic sections
Server communication
File processing
Draft recovery
Permission rules
Long-running operations
Multiple error sources

Consider a job application form.

Step 1 — Personal information
├── Name
├── Email
├── Phone
└── Location

Step 2 — Professional information
├── Current role
├── Total experience
└── Skills

Step 3 — Work experience
├── Experience 1
├── Experience 2
└── Add another experience

Step 4 — Documents
├── Resume
├── Cover letter
└── Portfolio

Step 5 — Review and submit

This is no longer just an object containing input values.

It is a workflow.

17.1 Multi-Step and Wizard Forms

A multi-step form divides one large form into smaller sections.

Large form
   ↓
Step 1
   ↓
Step 2
   ↓
Step 3
   ↓
Review
   ↓
Submit

This can reduce the amount of information shown at one time.

It can also improve completion when steps follow a meaningful sequence.

The problem

Imagine presenting 50 fields on one page.

The user may experience:

Cognitive overload
Difficulty locating errors
Long scrolling
Fear of losing progress
Uncertainty about how much work remains
Poor mobile usability

A wizard reduces visible complexity.

However, it introduces new questions:

When should each step be validated?
Should hidden steps remain registered?
Where should values be stored?
Can users navigate backward?
Should progress be saved?
What happens after a refresh?
Should users skip optional steps?

Multi-step state model

A wizard needs both form state and workflow state.

interface WizardState {
  currentStep: number;
  completedSteps: number[];
  draftId?: string;
}

The form library manages:

Values
Errors
Dirty fields
Touched fields

The wizard manages:

Current step
Completed steps
Navigation
Progress
Draft status

Do not mix these responsibilities unnecessarily.

Complete multi-step React Hook Form example

Install the required packages:

npm install react-hook-form zod @hookform/resolvers

Create application.schema.ts:

import { z } from "zod";

export const applicationSchema = z.object({
  personal: z.object({
    firstName: z
      .string()
      .trim()
      .min(1, "First name is required."),

    lastName: z
      .string()
      .trim()
      .min(1, "Last name is required."),

    email: z
      .string()
      .trim()
      .email("Enter a valid email address."),
  }),

  professional: z.object({
    currentRole: z
      .string()
      .trim()
      .min(1, "Current role is required."),

    yearsOfExperience: z.coerce
      .number()
      .min(
        0,
        "Experience cannot be negative.",
      )
      .max(
        60,
        "Enter a realistic amount of experience.",
      ),
  }),

  consent: z.boolean().refine(
    (value) => value,
    {
      message:
        "You must confirm that the information is accurate.",
    },
  ),
});

export type ApplicationInput = z.input<
  typeof applicationSchema
>;

export type ApplicationOutput = z.output<
  typeof applicationSchema
>;

Create ApplicationWizard.tsx:

import {
  useState,
} from "react";

import {
  FormProvider,
  useForm,
  useFormContext,
} from "react-hook-form";

import {
  zodResolver,
} from "@hookform/resolvers/zod";

import {
  applicationSchema,
} from "./application.schema";

import type {
  ApplicationInput,
  ApplicationOutput,
} from "./application.schema";

const defaultValues: ApplicationInput = {
  personal: {
    firstName: "",
    lastName: "",
    email: "",
  },

  professional: {
    currentRole: "",
    yearsOfExperience: 0,
  },

  consent: false,
};

const steps = [
  {
    title: "Personal information",

    fields: [
      "personal.firstName",
      "personal.lastName",
      "personal.email",
    ] as const,
  },

  {
    title: "Professional information",

    fields: [
      "professional.currentRole",
      "professional.yearsOfExperience",
    ] as const,
  },

  {
    title: "Review and submit",

    fields: [
      "consent",
    ] as const,
  },
];

function PersonalStep() {
  const {
    register,
    formState: {
      errors,
    },
  } = useFormContext<
    ApplicationInput
  >();

  return (
    <section>
      <h2>Personal information</h2>

      <div className="field">
        <label htmlFor="firstName">
          First name
        </label>

        <input
          id="firstName"
          autoComplete="given-name"
          aria-invalid={Boolean(
            errors.personal
              ?.firstName,
          )}
          aria-describedby={
            errors.personal
              ?.firstName
              ? "firstName-error"
              : undefined
          }
          {...register(
            "personal.firstName",
          )}
        />

        {errors.personal
          ?.firstName && (
          <p
            id="firstName-error"
            className="error"
          >
            {
              errors.personal
                .firstName
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="lastName">
          Last name
        </label>

        <input
          id="lastName"
          autoComplete="family-name"
          aria-invalid={Boolean(
            errors.personal
              ?.lastName,
          )}
          {...register(
            "personal.lastName",
          )}
        />

        {errors.personal
          ?.lastName && (
          <p className="error">
            {
              errors.personal
                .lastName
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="email">
          Email
        </label>

        <input
          id="email"
          type="email"
          autoComplete="email"
          aria-invalid={Boolean(
            errors.personal?.email,
          )}
          {...register(
            "personal.email",
          )}
        />

        {errors.personal?.email && (
          <p className="error">
            {
              errors.personal.email
                .message
            }
          </p>
        )}
      </div>
    </section>
  );
}

function ProfessionalStep() {
  const {
    register,
    formState: {
      errors,
    },
  } = useFormContext<
    ApplicationInput
  >();

  return (
    <section>
      <h2>
        Professional information
      </h2>

      <div className="field">
        <label htmlFor="currentRole">
          Current role
        </label>

        <input
          id="currentRole"
          aria-invalid={Boolean(
            errors.professional
              ?.currentRole,
          )}
          {...register(
            "professional.currentRole",
          )}
        />

        {errors.professional
          ?.currentRole && (
          <p className="error">
            {
              errors.professional
                .currentRole
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="experience">
          Years of experience
        </label>

        <input
          id="experience"
          type="number"
          min="0"
          max="60"
          aria-invalid={Boolean(
            errors.professional
              ?.yearsOfExperience,
          )}
          {...register(
            "professional.yearsOfExperience",
          )}
        />

        {errors.professional
          ?.yearsOfExperience && (
          <p className="error">
            {
              errors.professional
                .yearsOfExperience
                .message
            }
          </p>
        )}
      </div>
    </section>
  );
}

function ReviewStep() {
  const {
    register,
    getValues,
    formState: {
      errors,
    },
  } = useFormContext<
    ApplicationInput
  >();

  const values = getValues();

  return (
    <section>
      <h2>Review application</h2>

      <dl>
        <dt>Name</dt>
        <dd>
          {
            values.personal
              .firstName
          }{" "}
          {
            values.personal
              .lastName
          }
        </dd>

        <dt>Email</dt>
        <dd>
          {
            values.personal.email
          }
        </dd>

        <dt>Current role</dt>
        <dd>
          {
            values.professional
              .currentRole
          }
        </dd>

        <dt>Experience</dt>
        <dd>
          {
            values.professional
              .yearsOfExperience
          }{" "}
          years
        </dd>
      </dl>

      <label className="checkbox">
        <input
          type="checkbox"
          {...register("consent")}
        />

        <span>
          I confirm that this
          information is accurate.
        </span>
      </label>

      {errors.consent && (
        <p className="error">
          {errors.consent.message}
        </p>
      )}
    </section>
  );
}

export default function ApplicationWizard() {
  const [
    currentStep,
    setCurrentStep,
  ] = useState(0);

  const form =
    useForm<
      ApplicationInput,
      unknown,
      ApplicationOutput
    >({
      defaultValues,

      resolver:
        zodResolver(
          applicationSchema,
        ),

      mode: "onBlur",

      /*
       * Keep values from previous
       * steps after they unmount.
       */
      shouldUnregister: false,
    });

  const {
    handleSubmit,
    trigger,
    formState: {
      isSubmitting,
      isDirty,
    },
  } = form;

  async function goNext() {
    const fields =
      steps[currentStep].fields;

    const stepIsValid =
      await trigger(fields);

    if (!stepIsValid) {
      return;
    }

    setCurrentStep(
      (step) =>
        Math.min(
          step + 1,
          steps.length - 1,
        ),
    );
  }

  function goBack() {
    setCurrentStep(
      (step) =>
        Math.max(step - 1, 0),
    );
  }

  async function onSubmit(
    values: ApplicationOutput,
  ) {
    await new Promise(
      (resolve) => {
        setTimeout(
          resolve,
          1000,
        );
      },
    );

    console.log(
      "Submitted application:",
      values,
    );
  }

  return (
    <FormProvider {...form}>
      <form
        onSubmit={
          handleSubmit(onSubmit)
        }
        noValidate
      >
        <header>
          <p>
            Step {currentStep + 1} of{" "}
            {steps.length}
          </p>

          <h1>
            {
              steps[currentStep]
                .title
            }
          </h1>

          <progress
            value={
              currentStep + 1
            }
            max={steps.length}
          >
            {currentStep + 1} of{" "}
            {steps.length}
          </progress>
        </header>

        {currentStep === 0 && (
          <PersonalStep />
        )}

        {currentStep === 1 && (
          <ProfessionalStep />
        )}

        {currentStep === 2 && (
          <ReviewStep />
        )}

        <div className="actions">
          {currentStep > 0 && (
            <button
              type="button"
              onClick={goBack}
              disabled={
                isSubmitting
              }
            >
              Back
            </button>
          )}

          {currentStep <
          steps.length - 1 ? (
            <button
              type="button"
              onClick={goNext}
            >
              Continue
            </button>
          ) : (
            <button
              type="submit"
              disabled={
                isSubmitting
              }
            >
              {isSubmitting
                ? "Submitting..."
                : "Submit application"}
            </button>
          )}
        </div>

        {isDirty && (
          <p className="hint">
            You have unsaved
            changes.
          </p>
        )}
      </form>
    </FormProvider>
  );
}

Why use `FormProvider`?

Without FormProvider, every step would need methods passed through props.

Wizard
├── register
├── errors
├── control
├── setValue
└── getValues

FormProvider makes the form methods available through React context.

Nested step components can access them with:

const form =
  useFormContext<ApplicationInput>();

Use this when components belong to the same logical form.

Do not automatically place one giant form provider around the entire application.

Validate only the current step

This code:

await trigger(
  steps[currentStep].fields,
);

validates only the relevant fields.

Without it, clicking Continue might reveal errors in fields the user has not seen yet.

Step 1 Continue
       ↓
Validate Step 1
       ↓
Valid?
  /        \
No          Yes
↓            ↓
Show        Move to
errors      Step 2

Advantages of multi-step forms

Reduces visible complexity
Improves organization
Works well on small screens
Allows step-specific validation
Supports draft saving
Makes progress easier to understand
Can collect data in a meaningful sequence

Disadvantages

More workflow state
Users may lose context between steps
Back navigation must preserve values
Validation becomes step-dependent
Progress persistence requires additional architecture
Too many steps can make a short form feel longer
Hidden-step accessibility must be considered

Senior engineer tip

Do not divide a form into steps merely to appear modern.

A form containing four simple fields is usually better on one page.

Use steps when the sections represent meaningful tasks.

17.2 Conditional Fields

A conditional field appears only when another answer makes it relevant.

Example:

Are you currently employed?

Yes
 └── Company name
 └── Job title
 └── Notice period

No
 └── These fields are hidden

The problem

When a conditional field disappears, decide whether to:

Preserve its value
Remove its value
Remove its validation error
Submit it to the backend
Restore it if the user changes their answer again

These are product decisions.

Complete conditional-field example

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

interface EmploymentFormValues {
  employmentStatus:
    | ""
    | "employed"
    | "unemployed"
    | "student";

  companyName: string;
  jobTitle: string;
  collegeName: string;
}

export default function EmploymentForm() {
  const {
    register,
    handleSubmit,
    watch,
    formState: {
      errors,
    },
  } =
    useForm<EmploymentFormValues>({
      defaultValues: {
        employmentStatus: "",
        companyName: "",
        jobTitle: "",
        collegeName: "",
      },

      /*
       * Hidden fields are removed
       * from submitted form values.
       */
      shouldUnregister: true,
    });

  const employmentStatus =
    watch("employmentStatus");

  function onSubmit(
    values: EmploymentFormValues,
  ) {
    console.log(values);
  }

  return (
    <form
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <fieldset>
        <legend>
          Employment status
        </legend>

        <label>
          <input
            type="radio"
            value="employed"
            {...register(
              "employmentStatus",
              {
                required:
                  "Select your employment status.",
              },
            )}
          />
          Employed
        </label>

        <label>
          <input
            type="radio"
            value="unemployed"
            {...register(
              "employmentStatus",
            )}
          />
          Unemployed
        </label>

        <label>
          <input
            type="radio"
            value="student"
            {...register(
              "employmentStatus",
            )}
          />
          Student
        </label>

        {errors
          .employmentStatus && (
          <p className="error">
            {
              errors
                .employmentStatus
                .message
            }
          </p>
        )}
      </fieldset>

      {employmentStatus ===
        "employed" && (
        <>
          <div className="field">
            <label htmlFor="companyName">
              Company name
            </label>

            <input
              id="companyName"
              {...register(
                "companyName",
                {
                  required:
                    "Company name is required.",
                },
              )}
            />

            {errors.companyName && (
              <p className="error">
                {
                  errors.companyName
                    .message
                }
              </p>
            )}
          </div>

          <div className="field">
            <label htmlFor="jobTitle">
              Job title
            </label>

            <input
              id="jobTitle"
              {...register(
                "jobTitle",
                {
                  required:
                    "Job title is required.",
                },
              )}
            />

            {errors.jobTitle && (
              <p className="error">
                {
                  errors.jobTitle
                    .message
                }
              </p>
            )}
          </div>
        </>
      )}

      {employmentStatus ===
        "student" && (
        <div className="field">
          <label htmlFor="collegeName">
            College name
          </label>

          <input
            id="collegeName"
            {...register(
              "collegeName",
              {
                required:
                  "College name is required.",
              },
            )}
          />

          {errors.collegeName && (
            <p className="error">
              {
                errors.collegeName
                  .message
              }
            </p>
          )}
        </div>
      )}

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

`shouldUnregister` decision

Use:

shouldUnregister: true

when hidden fields should be removed.

Use:

shouldUnregister: false

when hidden sections should retain progress.

Example:

Checkout shipping address
→ Preserve when temporarily hidden

Employment fields after selecting unemployed
→ Usually remove from submitted data

Advantages

Users see only relevant questions
Reduces unnecessary work
Produces cleaner workflows
Can improve completion rates
Supports personalized forms

Disadvantages

Hidden data may remain accidentally
Errors can remain after fields disappear
Conditional rules can become hard to understand
Accessibility announcements may be needed
Complex dependency chains create maintenance risk

17.3 Dynamic Arrays with `useFieldArray`

Dynamic arrays allow users to add repeated groups.

Examples:

Work experiences
Education records
Emergency contacts
Product items
Addresses
Interview questions
Team members

React Hook Form provides useFieldArray() for appending, removing, inserting, moving, and replacing repeated field groups.

The problem

Suppose a candidate adds three experiences.

{
  experiences: [
    {
      company: "Company A",
      role: "Intern"
    },
    {
      company: "Company B",
      role: "Developer"
    },
    {
      company: "Company C",
      role: "Engineer"
    }
  ]
}

Each item requires:

A stable identity
Nested registration paths
Error mapping
Add and remove operations
Correct rendering after reordering

Using only the array index as the React key can cause incorrect UI reuse after removing or moving items.

useFieldArray() returns field objects containing stable generated identifiers for rendering.

Complete work-experience example

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

interface Experience {
  company: string;
  role: string;
  startDate: string;
  endDate: string;
  currentlyWorking: boolean;
}

interface ResumeFormValues {
  experiences: Experience[];
}

const emptyExperience:
  Experience = {
    company: "",
    role: "",
    startDate: "",
    endDate: "",
    currentlyWorking: false,
  };

export default function ExperienceForm() {
  const {
    register,
    control,
    handleSubmit,
    watch,
    formState: {
      errors,
    },
  } =
    useForm<ResumeFormValues>({
      defaultValues: {
        experiences: [
          emptyExperience,
        ],
      },
    });

  const {
    fields,
    append,
    remove,
    move,
  } = useFieldArray({
    control,
    name: "experiences",
  });

  const experiences =
    watch("experiences");

  function onSubmit(
    values: ResumeFormValues,
  ) {
    console.log(values);
  }

  return (
    <form
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <h1>Work experience</h1>

      {fields.map(
        (field, index) => {
          const currentlyWorking =
            experiences?.[index]
              ?.currentlyWorking;

          const experienceErrors =
            errors.experiences
              ?.[index];

          return (
            <fieldset
              key={field.id}
            >
              <legend>
                Experience{" "}
                {index + 1}
              </legend>

              <div className="field">
                <label
                  htmlFor={`company-${index}`}
                >
                  Company
                </label>

                <input
                  id={`company-${index}`}
                  {...register(
                    `experiences.${index}.company`,
                    {
                      required:
                        "Company is required.",
                    },
                  )}
                />

                {experienceErrors
                  ?.company && (
                  <p className="error">
                    {
                      experienceErrors
                        .company
                        .message
                    }
                  </p>
                )}
              </div>

              <div className="field">
                <label
                  htmlFor={`role-${index}`}
                >
                  Role
                </label>

                <input
                  id={`role-${index}`}
                  {...register(
                    `experiences.${index}.role`,
                    {
                      required:
                        "Role is required.",
                    },
                  )}
                />

                {experienceErrors
                  ?.role && (
                  <p className="error">
                    {
                      experienceErrors
                        .role
                        .message
                    }
                  </p>
                )}
              </div>

              <div className="field">
                <label
                  htmlFor={`start-${index}`}
                >
                  Start date
                </label>

                <input
                  id={`start-${index}`}
                  type="month"
                  {...register(
                    `experiences.${index}.startDate`,
                    {
                      required:
                        "Start date is required.",
                    },
                  )}
                />
              </div>

              <label>
                <input
                  type="checkbox"
                  {...register(
                    `experiences.${index}.currentlyWorking`,
                  )}
                />

                I currently work here
              </label>

              {!currentlyWorking && (
                <div className="field">
                  <label
                    htmlFor={`end-${index}`}
                  >
                    End date
                  </label>

                  <input
                    id={`end-${index}`}
                    type="month"
                    {...register(
                      `experiences.${index}.endDate`,
                      {
                        required:
                          "End date is required.",
                      },
                    )}
                  />

                  {experienceErrors
                    ?.endDate && (
                    <p className="error">
                      {
                        experienceErrors
                          .endDate
                          .message
                      }
                    </p>
                  )}
                </div>
              )}

              <div className="actions">
                <button
                  type="button"
                  onClick={() => {
                    remove(index);
                  }}
                  disabled={
                    fields.length ===
                    1
                  }
                >
                  Remove
                </button>

                {index > 0 && (
                  <button
                    type="button"
                    onClick={() => {
                      move(
                        index,
                        index - 1,
                      );
                    }}
                  >
                    Move up
                  </button>
                )}
              </div>
            </fieldset>
          );
        },
      )}

      <button
        type="button"
        onClick={() => {
          append({
            ...emptyExperience,
          });
        }}
      >
        Add experience
      </button>

      <button type="submit">
        Save experiences
      </button>
    </form>
  );
}

Why use `field.id` as the React key?

Correct:

key={field.id}

Risky:

key={index}

When an item is removed, array indexes change.

React may reuse the wrong rendered element if the index is treated as its identity.

The generated field ID remains stable for that item.

Dynamic error paths

For the second experience's company:

errors.experiences?.[1]?.company

The path is:

experiences
    ↓
index 1
    ↓
company

This mirrors the form value structure.

Advantages

Supports repeated groups
Stable item identifiers
Built-in array operations
Nested error support
Better performance than rebuilding array state manually
Works naturally with form submission

Disadvantages

Nested TypeScript paths can become complex
Index-based server errors must map correctly
Reordering may affect business identifiers
Large arrays can produce long pages
Removing items may require confirmation
Backend IDs and frontend generated IDs must not be confused

Senior engineer tip

The generated field.id is a UI identity.

A database record may also have:

databaseId: string;

Do not assume they are the same.

{
  id: "react-hook-form-render-key",
  databaseId: "persistent-database-record"
}

17.4 Nested Objects

Form structures should normally resemble the domain data they produce.

Instead of:

{
  addressCountry: "India",
  addressState: "Andhra Pradesh",
  addressCity: "Kadapa"
}

you may use:

{
  address: {
    country: "India",
    state: "Andhra Pradesh",
    city: "Kadapa"
  }
}

<input
  {...register(
    "address.country",
  )}
/>

<input
  {...register(
    "address.state",
  )}
/>

Errors follow the same shape:

errors.address?.country

Complete nested-object example

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

interface CheckoutValues {
  customer: {
    firstName: string;
    lastName: string;
    email: string;
  };

  shippingAddress: {
    street: string;
    city: string;
    state: string;
    postalCode: string;
    country: string;
  };
}

export default function CheckoutForm() {
  const {
    register,
    handleSubmit,
    formState: {
      errors,
    },
  } =
    useForm<CheckoutValues>({
      defaultValues: {
        customer: {
          firstName: "",
          lastName: "",
          email: "",
        },

        shippingAddress: {
          street: "",
          city: "",
          state: "",
          postalCode: "",
          country: "",
        },
      },
    });

  return (
    <form
      onSubmit={handleSubmit(
        console.log,
      )}
    >
      <fieldset>
        <legend>
          Customer details
        </legend>

        <input
          placeholder="First name"
          {...register(
            "customer.firstName",
            {
              required:
                "First name is required.",
            },
          )}
        />

        {errors.customer
          ?.firstName && (
          <p className="error">
            {
              errors.customer
                .firstName.message
            }
          </p>
        )}

        <input
          placeholder="Last name"
          {...register(
            "customer.lastName",
            {
              required:
                "Last name is required.",
            },
          )}
        />

        <input
          type="email"
          placeholder="Email"
          {...register(
            "customer.email",
            {
              required:
                "Email is required.",
            },
          )}
        />
      </fieldset>

      <fieldset>
        <legend>
          Shipping address
        </legend>

        <input
          placeholder="Street"
          autoComplete="shipping street-address"
          {...register(
            "shippingAddress.street",
            {
              required:
                "Street is required.",
            },
          )}
        />

        <input
          placeholder="City"
          autoComplete="shipping address-level2"
          {...register(
            "shippingAddress.city",
            {
              required:
                "City is required.",
            },
          )}
        />

        <input
          placeholder="State"
          autoComplete="shipping address-level1"
          {...register(
            "shippingAddress.state",
            {
              required:
                "State is required.",
            },
          )}
        />

        <input
          placeholder="Postal code"
          autoComplete="shipping postal-code"
          {...register(
            "shippingAddress.postalCode",
            {
              required:
                "Postal code is required.",
            },
          )}
        />

        <input
          placeholder="Country"
          autoComplete="shipping country-name"
          {...register(
            "shippingAddress.country",
            {
              required:
                "Country is required.",
            },
          )}
        />
      </fieldset>

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

Browsers can use specific autocomplete tokens as hints for prefilling names, addresses, postal codes, and other recognized values.

17.5 File Uploads

File fields differ from ordinary text inputs.

A text field produces:

email: string

A file input produces a FileList.

<input
  type="file"
  {...register("resume")}
/>

The selected files are accessible through the browser's file-input APIs. A file input can support multiple files, while the files property contains the selected File objects.

The problem

A production upload may require:

Type validation
Size validation
Preview
Upload progress
Cancellation
Retry
Direct cloud upload
Virus scanning
Server verification
Persistent file metadata

The HTML accept attribute helps filter the file picker, but it is only a hint and must not replace server validation.

Complete resume-upload example

import {
  useState,
} from "react";

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

interface ResumeFormValues {
  candidateName: string;
  resume: FileList;
}

const MAX_FILE_SIZE =
  5 * 1024 * 1024;

const allowedTypes = [
  "application/pdf",
];

export default function ResumeUploadForm() {
  const [
    selectedFileName,
    setSelectedFileName,
  ] = useState("");

  const {
    register,
    handleSubmit,
    setError,
    clearErrors,
    reset,
    formState: {
      errors,
      isSubmitting,
    },
  } =
    useForm<ResumeFormValues>();

  const resumeRegistration =
    register("resume", {
      required:
        "Select a resume.",

      validate: {
        oneFile: (
          files,
        ) =>
          files.length === 1 ||
          "Select exactly one file.",

        allowedType: (
          files,
        ) => {
          const file =
            files.item(0);

          return (
            !file ||
            allowedTypes.includes(
              file.type,
            ) ||
            "Only PDF files are allowed."
          );
        },

        fileSize: (
          files,
        ) => {
          const file =
            files.item(0);

          return (
            !file ||
            file.size <=
              MAX_FILE_SIZE ||
            "The resume must be 5 MB or smaller."
          );
        },
      },
    });

  async function onSubmit(
    values: ResumeFormValues,
  ) {
    const resume =
      values.resume.item(0);

    if (!resume) {
      setError("resume", {
        type: "manual",
        message:
          "Select a resume.",
      });

      return;
    }

    const body =
      new FormData();

    body.append(
      "candidateName",
      values.candidateName,
    );

    body.append(
      "resume",
      resume,
    );

    const response =
      await fetch(
        "/api/applications",
        {
          method: "POST",
          body,
        },
      );

    if (!response.ok) {
      setError(
        "root.server",
        {
          type: "server",
          message:
            "The resume could not be uploaded.",
        },
      );

      return;
    }

    reset();
    setSelectedFileName("");
  }

  return (
    <form
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <div className="field">
        <label htmlFor="candidateName">
          Candidate name
        </label>

        <input
          id="candidateName"
          {...register(
            "candidateName",
            {
              required:
                "Candidate name is required.",
            },
          )}
        />

        {errors.candidateName && (
          <p className="error">
            {
              errors.candidateName
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="resume">
          Resume
        </label>

        <input
          id="resume"
          type="file"
          accept=".pdf,application/pdf"
          aria-describedby="resume-hint resume-error"
          {...resumeRegistration}
          onChange={(event) => {
            resumeRegistration
              .onChange(event);

            clearErrors("resume");

            setSelectedFileName(
              event.target.files
                ?.item(0)?.name ??
                "",
            );
          }}
        />

        <p id="resume-hint">
          Upload one PDF, maximum
          size 5 MB.
        </p>

        {selectedFileName && (
          <p>
            Selected:{" "}
            {selectedFileName}
          </p>
        )}

        {errors.resume && (
          <p
            id="resume-error"
            className="error"
          >
            {String(
              errors.resume
                .message,
            )}
          </p>
        )}
      </div>

      {errors.root?.server && (
        <p
          className="error"
          role="alert"
        >
          {
            errors.root.server
              .message
          }
        </p>
      )}

      <button
        type="submit"
        disabled={isSubmitting}
      >
        {isSubmitting
          ? "Uploading..."
          : "Submit application"}
      </button>
    </form>
  );
}

Do not manually set multipart content type

When sending FormData, avoid:

headers: {
  "Content-Type":
    "multipart/form-data"
}

The browser must generate the multipart boundary.

Use:

fetch("/api/upload", {
  method: "POST",
  body: formData,
});

Server validation is mandatory

The backend must verify:

Actual file size
Actual content type
File signature where needed
Authorized uploader
Number of files
Storage path
Malware-scanning result
Whether the file is expected by the workflow

Client-side checks improve feedback but are not trustworthy.

17.6 Drag-and-Drop Uploads

Drag and drop should enhance a normal file input, not replace it.

A hidden or visually customized file input still provides:

Keyboard access
Native file picker
Screen-reader semantics
Mobile support

Complete drop-zone example

import {
  DragEvent,
  useRef,
  useState,
} from "react";

interface DropZoneProps {
  onFileSelected:
    (file: File) => void;
  acceptLabel: string;
}

export default function DropZone({
  onFileSelected,
  acceptLabel,
}: DropZoneProps) {
  const inputRef =
    useRef<HTMLInputElement>(
      null,
    );

  const [
    isDragging,
    setIsDragging,
  ] = useState(false);

  function selectFile(
    files:
      | FileList
      | null,
  ) {
    const file =
      files?.item(0);

    if (file) {
      onFileSelected(file);
    }
  }

  function handleDrop(
    event:
      DragEvent<HTMLDivElement>,
  ) {
    event.preventDefault();

    setIsDragging(false);

    selectFile(
      event.dataTransfer.files,
    );
  }

  return (
    <div>
      <input
        ref={inputRef}
        id="resume"
        type="file"
        accept=".pdf,application/pdf"
        onChange={(event) => {
          selectFile(
            event.target.files,
          );
        }}
      />

      <div
        className={
          isDragging
            ? "drop-zone active"
            : "drop-zone"
        }
        onDragEnter={(
          event,
        ) => {
          event.preventDefault();
          setIsDragging(true);
        }}
        onDragOver={(event) => {
          event.preventDefault();
        }}
        onDragLeave={() => {
          setIsDragging(false);
        }}
        onDrop={handleDrop}
      >
        <p>
          Drag your resume here
          or use the file picker.
        </p>

        <button
          type="button"
          onClick={() => {
            inputRef.current
              ?.click();
          }}
        >
          Choose file
        </button>

        <p>{acceptLabel}</p>
      </div>
    </div>
  );
}

The real file input remains available.

The drop zone is an additional interaction method.

17.7 Debounced Validation

Some validation requires a server request.

Examples:

Username availability
Coupon validity
Organization slug availability
Tax number verification
Address suggestions

Sending a request on every keystroke is wasteful.

k
ka
kar
kart
karth
karthik

Without debouncing, that could produce seven requests.

Complete debounced username check

import {
  useEffect,
  useState,
} from "react";

interface UsernameStatus {
  state:
    | "idle"
    | "checking"
    | "available"
    | "unavailable"
    | "error";

  message: string;
}

export function useUsernameCheck(
  username: string,
): UsernameStatus {
  const [
    status,
    setStatus,
  ] =
    useState<UsernameStatus>({
      state: "idle",
      message: "",
    });

  useEffect(() => {
    const normalized =
      username
        .trim()
        .toLowerCase();

    if (
      normalized.length < 3
    ) {
      setStatus({
        state: "idle",
        message: "",
      });

      return;
    }

    const controller =
      new AbortController();

    const timeoutId =
      window.setTimeout(
        async () => {
          setStatus({
            state:
              "checking",
            message:
              "Checking availability...",
          });

          try {
            const response =
              await fetch(
                `/api/usernames/${encodeURIComponent(
                  normalized,
                )}/availability`,
                {
                  signal:
                    controller.signal,
                },
              );

            if (!response.ok) {
              throw new Error(
                "Availability request failed.",
              );
            }

            const result =
              (await response.json()) as {
                available: boolean;
              };

            setStatus(
              result.available
                ? {
                    state:
                      "available",
                    message:
                      "Username is available.",
                  }
                : {
                    state:
                      "unavailable",
                    message:
                      "Username is already taken.",
                  },
            );
          } catch (error) {
            if (
              error instanceof
                DOMException &&
              error.name ===
                "AbortError"
            ) {
              return;
            }

            setStatus({
              state: "error",
              message:
                "Unable to check availability.",
            });
          }
        },
        400,
      );

    return () => {
      window.clearTimeout(
        timeoutId,
      );

      controller.abort();
    };
  }, [username]);

  return status;
}

Usage:

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

interface UsernameFormValues {
  username: string;
}

export default function UsernameForm() {
  const {
    register,
    control,
    setError,
    clearErrors,
    handleSubmit,
  } =
    useForm<UsernameFormValues>({
      defaultValues: {
        username: "",
      },
    });

  const username =
    useWatch({
      control,
      name: "username",
    });

  const status =
    useUsernameCheck(username);

  useEffect(() => {
    if (
      status.state ===
      "unavailable"
    ) {
      setError("username", {
        type: "server",
        message:
          status.message,
      });
    }

    if (
      status.state ===
      "available"
    ) {
      clearErrors("username");
    }
  }, [
    status,
    setError,
    clearErrors,
  ]);

  return (
    <form
      onSubmit={handleSubmit(
        console.log,
      )}
    >
      <input
        {...register("username")}
      />

      <p
        role="status"
        aria-live="polite"
      >
        {status.message}
      </p>

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

Race-condition protection

Debouncing reduces requests.

Aborting prevents an old request from overwriting a newer answer.

Request: "kart"
Request: "karthik"

"karthik" response arrives
        ↓
"kart" response arrives later

Without cancellation or request-version checking, the old result may incorrectly replace the current result.

Never rely on availability checks as a guarantee

A username may be available during typing and taken one second later.

The backend must perform the authoritative check during submission.

17.8 Autosave and Draft Saving

Autosave stores progress while the user is editing.

Draft saving is valuable for:

Long applications
Content editors
Medical or government forms
Multi-step onboarding
Surveys
Complex business records

The autosave state machine

Idle
  ↓
User edits
  ↓
Unsaved
  ↓
Saving
  ├──→ Saved
  └──→ Failed

A production UI should communicate this state.

Unsaved changes
Saving...
Saved at 11:42
Could not save draft

Local draft example

import {
  useEffect,
} from "react";

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

interface DraftValues {
  title: string;
  description: string;
  notes: string;
}

const STORAGE_KEY =
  "project-draft-v1";

function loadDraft():
  DraftValues {
  const stored =
    window.localStorage
      .getItem(STORAGE_KEY);

  if (!stored) {
    return {
      title: "",
      description: "",
      notes: "",
    };
  }

  try {
    return JSON.parse(
      stored,
    ) as DraftValues;
  } catch {
    return {
      title: "",
      description: "",
      notes: "",
    };
  }
}

export default function DraftForm() {
  const {
    register,
    control,
    handleSubmit,
    reset,
  } =
    useForm<DraftValues>({
      defaultValues:
        loadDraft(),
    });

  const values =
    useWatch({
      control,
    });

  useEffect(() => {
    const timeoutId =
      window.setTimeout(
        () => {
          window.localStorage
            .setItem(
              STORAGE_KEY,
              JSON.stringify(
                values,
              ),
            );
        },
        500,
      );

    return () => {
      window.clearTimeout(
        timeoutId,
      );
    };
  }, [values]);

  async function onSubmit(
    submittedValues:
      DraftValues,
  ) {
    console.log(
      submittedValues,
    );

    window.localStorage
      .removeItem(
        STORAGE_KEY,
      );

    reset();
  }

  return (
    <form
      onSubmit={
        handleSubmit(onSubmit)
      }
    >
      <input
        placeholder="Title"
        {...register("title")}
      />

      <textarea
        placeholder="Description"
        {...register(
          "description",
        )}
      />

      <textarea
        placeholder="Notes"
        {...register("notes")}
      />

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

Security warning

Do not place highly sensitive data in localStorage.

Examples that require stronger protection include:

Passwords
Authentication tokens
Payment details
Confidential health information
Highly sensitive identity documents

Local storage is readable by JavaScript running on the same origin.

For sensitive drafts, prefer authenticated server-side storage with appropriate access control and encryption.

Server-side autosave hook

import {
  useEffect,
  useRef,
  useState,
} from "react";

interface AutosaveOptions<T> {
  values: T;
  enabled: boolean;
  save:
    (
      values: T,
      signal: AbortSignal,
    ) => Promise<void>;
  delay?: number;
}

export function useAutosave<T>({
  values,
  enabled,
  save,
  delay = 1000,
}: AutosaveOptions<T>) {
  const [
    status,
    setStatus,
  ] = useState<
    | "idle"
    | "unsaved"
    | "saving"
    | "saved"
    | "error"
  >("idle");

  const firstRender =
    useRef(true);

  useEffect(() => {
    if (
      firstRender.current
    ) {
      firstRender.current =
        false;

      return;
    }

    if (!enabled) {
      return;
    }

    setStatus("unsaved");

    const controller =
      new AbortController();

    const timeoutId =
      window.setTimeout(
        async () => {
          setStatus("saving");

          try {
            await save(
              values,
              controller.signal,
            );

            setStatus("saved");
          } catch (error) {
            if (
              error instanceof
                DOMException &&
              error.name ===
                "AbortError"
            ) {
              return;
            }

            setStatus("error");
          }
        },
        delay,
      );

    return () => {
      window.clearTimeout(
        timeoutId,
      );

      controller.abort();
    };
  }, [
    values,
    enabled,
    save,
    delay,
  ]);

  return status;
}

Autosave design questions

Before implementing autosave, answer:

What is the draft identifier?
Does each user have one draft or many?
How are concurrent browser tabs handled?
What happens when the server version is newer?
Can offline edits be merged?
How are conflicts presented?
How long are drafts retained?
Which fields are excluded from saving?
Does the user know their data is being stored?

Autosave is a data-consistency feature, not only a timer.

17.9 Optimistic UI

Optimistic UI updates the interface before the server confirms success.

Example:

User adds a skill
       ↓
Skill appears immediately
       ↓
Request is sent
       ↓
Success → keep it
Failure → remove it and show error

Complete optimistic skill example

import {
  useState,
} from "react";

interface Skill {
  id: string;
  name: string;
  status:
    | "saving"
    | "saved"
    | "failed";
}

export default function SkillsEditor() {
  const [
    skills,
    setSkills,
  ] = useState<Skill[]>([]);

  const [
    input,
    setInput,
  ] = useState("");

  async function addSkill() {
    const name =
      input.trim();

    if (!name) {
      return;
    }

    const temporaryId =
      crypto.randomUUID();

    const optimisticSkill:
      Skill = {
        id: temporaryId,
        name,
        status: "saving",
      };

    setSkills(
      (currentSkills) => [
        ...currentSkills,
        optimisticSkill,
      ],
    );

    setInput("");

    try {
      const response =
        await fetch(
          "/api/skills",
          {
            method: "POST",

            headers: {
              "Content-Type":
                "application/json",
            },

            body:
              JSON.stringify({
                name,
              }),
          },
        );

      if (!response.ok) {
        throw new Error(
          "Unable to save skill.",
        );
      }

      const result =
        (await response.json()) as {
          skill: {
            id: string;
            name: string;
          };
        };

      setSkills(
        (currentSkills) =>
          currentSkills.map(
            (skill) =>
              skill.id ===
              temporaryId
                ? {
                    ...result.skill,
                    status:
                      "saved",
                  }
                : skill,
          ),
      );
    } catch {
      setSkills(
        (currentSkills) =>
          currentSkills.map(
            (skill) =>
              skill.id ===
              temporaryId
                ? {
                    ...skill,
                    status:
                      "failed",
                  }
                : skill,
          ),
      );
    }
  }

  return (
    <section>
      <h2>Skills</h2>

      <input
        value={input}
        onChange={(event) => {
          setInput(
            event.target.value,
          );
        }}
      />

      <button
        type="button"
        onClick={addSkill}
      >
        Add skill
      </button>

      <ul>
        {skills.map((skill) => (
          <li key={skill.id}>
            {skill.name}

            {skill.status ===
              "saving" && (
              <span>
                {" "}
                Saving...
              </span>
            )}

            {skill.status ===
              "failed" && (
              <span
                className="error"
              >
                {" "}
                Could not save
              </span>
            )}
          </li>
        ))}
      </ul>
    </section>
  );
}

When optimistic UI is appropriate

Good candidates:

Adding a tag
Toggling a preference
Liking an item
Reordering a list
Updating low-risk profile metadata

Riskier candidates:

Final payment confirmation
Legal acceptance
Account deletion
Irreversible operations
Limited inventory allocation
High-value financial actions

The interface must not claim success before confirmation when incorrect success could cause serious harm.

Enterprise Form Advantages

Handles complex workflows
Supports large domain objects
Preserves long-running progress
Improves organization
Supports dynamic user needs
Enables richer feedback
Provides reusable infrastructure

Enterprise Form Disadvantages

More state transitions
More backend endpoints
More concurrency problems
Larger testing surface
Accessibility becomes harder
Draft and autosave security must be designed
Error handling becomes distributed
More opportunities for stale state

Why this evolved

Modern products require forms to behave like complete applications. Developers therefore moved from individual components toward feature-based form architecture with schemas, API layers, shared UI components, testing, observability, and explicit workflow state.

Stage 18: Modern Production Form Architecture

A production form should not normally live in one 1,000-line component.

A large component often mixes:

UI markup
Validation schema
API requests
Error conversion
Analytics
Navigation
File upload logic
Draft saving
Business rules

This makes changes dangerous.

A better architecture separates responsibilities.

Recommended feature structure

src/
├── components/
│   └── forms/
│       ├── FormField.tsx
│       ├── FormError.tsx
│       ├── ErrorSummary.tsx
│       ├── SubmitButton.tsx
│       └── FileField.tsx
│
├── features/
│   └── applications/
│       ├── api/
│       │   ├── create-application.ts
│       │   ├── save-draft.ts
│       │   └── upload-resume.ts
│       │
│       ├── components/
│       │   ├── ApplicationForm.tsx
│       │   ├── PersonalStep.tsx
│       │   ├── ExperienceStep.tsx
│       │   └── ReviewStep.tsx
│       │
│       ├── hooks/
│       │   ├── use-application-draft.ts
│       │   └── use-resume-upload.ts
│       │
│       ├── schemas/
│       │   └── application.schema.ts
│       │
│       ├── types/
│       │   └── application.types.ts
│       │
│       └── utils/
│           └── map-api-errors.ts
│
├── lib/
│   ├── api-client.ts
│   └── logger.ts
│
└── app/
    └── applications/
        └── page.tsx

Responsibility boundaries

Schema

What input shape is valid?

Form component

How does the user interact with it?

API function

How is data sent to the server?

Error mapper

How do server errors become field errors?

Reusable field component

How are labels, hints, inputs,
and errors rendered consistently?

Page or route

Where does the user go after success?

18.1 Reusable `FormField`

A reusable component should manage presentation and accessibility.

It should not own business validation.

import {
  forwardRef,
} from "react";

import type {
  InputHTMLAttributes,
  ReactNode,
} from "react";

interface FormFieldProps
  extends InputHTMLAttributes<HTMLInputElement> {
  id: string;
  label: string;
  error?: string;
  hint?: ReactNode;
}

const FormField =
  forwardRef<
    HTMLInputElement,
    FormFieldProps
  >(function FormField(
    {
      id,
      label,
      error,
      hint,
      required,
      ...inputProps
    },
    ref,
  ) {
    const hintId =
      hint
        ? `${id}-hint`
        : undefined;

    const errorId =
      error
        ? `${id}-error`
        : undefined;

    const describedBy = [
      hintId,
      errorId,
    ]
      .filter(Boolean)
      .join(" ") || undefined;

    return (
      <div className="field">
        <label htmlFor={id}>
          {label}

          {required && (
            <span
              aria-hidden="true"
            >
              {" *"}
            </span>
          )}
        </label>

        <input
          {...inputProps}
          id={id}
          ref={ref}
          required={required}
          aria-invalid={Boolean(
            error,
          )}
          aria-describedby={
            describedBy
          }
        />

        {hint && (
          <p
            id={hintId}
            className="hint"
          >
            {hint}
          </p>
        )}

        {error && (
          <p
            id={errorId}
            className="error"
          >
            {error}
          </p>
        )}
      </div>
    );
  });

export default FormField;

What this component should handle

Label association
Hint IDs
Error IDs
aria-invalid
aria-describedby
Consistent styling
Ref forwarding

What it should not handle

Email uniqueness
API requests
Redirects
Password policies
Database rules
Toast notifications

18.2 Reusable Form Error

interface FormErrorProps {
  message?: string;
}

export default function FormError({
  message,
}: FormErrorProps) {
  if (!message) {
    return null;
  }

  return (
    <div
      className="form-error"
      role="alert"
    >
      <strong>
        We could not submit
        the form.
      </strong>

      <p>{message}</p>
    </div>
  );
}

Use field errors beside fields.

Use FormError for form-wide failures.

18.3 Schema Organization

Small feature:

register.schema.ts

Large feature:

schemas/
├── personal.schema.ts
├── experience.schema.ts
├── document.schema.ts
└── application.schema.ts

Composable schemas:

import { z } from "zod";

export const personalSchema =
  z.object({
    firstName:
      z.string().min(1),

    lastName:
      z.string().min(1),

    email:
      z.string().email(),
  });

export const experienceSchema =
  z.object({
    company:
      z.string().min(1),

    role:
      z.string().min(1),

    startDate:
      z.string().min(1),

    endDate:
      z.string().optional(),
  });

export const applicationSchema =
  z.object({
    personal:
      personalSchema,

    experiences:
      z
        .array(
          experienceSchema,
        )
        .min(
          1,
          "Add at least one experience.",
        ),
  });

18.4 API Layer

Bad:

async function onSubmit(values) {
  const response =
    await fetch(...);

  if (response.status === 409) {
    // Parse backend
  }

  if (response.status === 401) {
    // Refresh session
  }

  if (response.status === 500) {
    // Log error
  }
}

This becomes duplicated across forms.

Create an API client.

export class HttpError<
  TData = unknown,
> extends Error {
  status: number;
  data: TData;

  constructor(
    status: number,
    data: TData,
    message:
      string = "Request failed.",
  ) {
    super(message);

    this.name =
      "HttpError";

    this.status = status;
    this.data = data;
  }
}

export async function apiRequest<
  TResponse,
>(
  url: string,
  options?: RequestInit,
): Promise<TResponse> {
  const response =
    await fetch(url, {
      ...options,

      headers: {
        "Content-Type":
          "application/json",

        ...options?.headers,
      },
    });

  const data =
    (await response.json()) as
      | TResponse
      | {
          message?: string;
        };

  if (!response.ok) {
    throw new HttpError(
      response.status,
      data,
      "message" in data
        ? data.message
        : "Request failed.",
    );
  }

  return data as TResponse;
}

Feature API function:

import type {
  ApplicationOutput,
} from "../schemas/application.schema";

interface CreateApplicationResponse {
  success: true;

  data: {
    applicationId: string;
  };
}

export function createApplication(
  input: ApplicationOutput,
) {
  return apiRequest<
    CreateApplicationResponse
  >(
    "/api/applications",
    {
      method: "POST",

      body:
        JSON.stringify(input),
    },
  );
}

The form does not need to know every Fetch detail.

18.5 Loading States

Loading is not one universal Boolean.

A complex form may contain:

isLoadingInitialData
isCheckingUsername
isSavingDraft
isUploadingResume
isSubmitting
isRedirecting

Do not combine every operation into:

const [loading, setLoading] =
  useState(false);

Use specific states.

interface ApplicationStatus {
  draft:
    | "idle"
    | "saving"
    | "saved"
    | "error";

  resume:
    | "idle"
    | "uploading"
    | "uploaded"
    | "error";

  submission:
    | "idle"
    | "submitting"
    | "success"
    | "error";
}

This prevents invalid UI behavior.

18.6 Toast Notifications

Toasts are useful for global, temporary feedback.

Good toast examples:

Draft saved.
Profile updated.
Invitation sent.
File uploaded.

Poor toast-only examples:

Email is invalid.
Password is too short.
City is required.

Field validation should remain beside the relevant field.

Simple toast state example

import {
  useState,
} from "react";

interface Toast {
  id: string;
  message: string;
  type:
    | "success"
    | "error";
}

export default function SaveForm() {
  const [
    toasts,
    setToasts,
  ] = useState<Toast[]>([]);

  function showToast(
    message: string,
    type:
      | "success"
      | "error",
  ) {
    const toast: Toast = {
      id:
        crypto.randomUUID(),
      message,
      type,
    };

    setToasts(
      (current) => [
        ...current,
        toast,
      ],
    );

    window.setTimeout(
      () => {
        setToasts(
          (current) =>
            current.filter(
              (item) =>
                item.id !==
                toast.id,
            ),
        );
      },
      4000,
    );
  }

  async function save() {
    try {
      await Promise.resolve();

      showToast(
        "Changes saved.",
        "success",
      );
    } catch {
      showToast(
        "Unable to save changes.",
        "error",
      );
    }
  }

  return (
    <>
      <button
        type="button"
        onClick={save}
      >
        Save
      </button>

      <div
        aria-live="polite"
        aria-atomic="false"
      >
        {toasts.map(
          (toast) => (
            <div
              key={toast.id}
              className={
                `toast ${toast.type}`
              }
            >
              {toast.message}
            </div>
          ),
        )}
      </div>
    </>
  );
}

In a real application, a tested toast library can handle timing, stacking, focus, dismissal, and animation.

18.7 Error Boundaries

Error boundaries handle unexpected rendering failures.

They do not replace normal form-error handling.

Use form state for expected failures:

Email already exists
Invalid coupon
Server rejected input

Use an error boundary for unexpected failures:

Component crashed
Unexpected JavaScript exception
Rendering failure

Complete class error boundary

import {
  Component,
} from "react";

import type {
  ErrorInfo,
  ReactNode,
} from "react";

interface ErrorBoundaryProps {
  children: ReactNode;
}

interface ErrorBoundaryState {
  hasError: boolean;
}

export default class ErrorBoundary extends Component<
  ErrorBoundaryProps,
  ErrorBoundaryState
> {
  state:
    ErrorBoundaryState = {
      hasError: false,
    };

  static getDerivedStateFromError():
    ErrorBoundaryState {
    return {
      hasError: true,
    };
  }

  componentDidCatch(
    error: Error,
    info: ErrorInfo,
  ) {
    console.error(
      "Unexpected form error:",
      error,
      info,
    );

    /*
     * Send the error to your
     * monitoring system here.
     */
  }

  render() {
    if (
      this.state.hasError
    ) {
      return (
        <section role="alert">
          <h1>
            Something went wrong
          </h1>

          <p>
            Reload the page and try
            again. Your server-saved
            draft is still available.
          </p>

          <button
            type="button"
            onClick={() => {
              window.location
                .reload();
            }}
          >
            Reload page
          </button>
        </section>
      );
    }

    return this.props.children;
  }
}

18.8 Form Error Mapping

Create one tested utility for mapping backend fields.

import type {
  FieldPath,
  FieldValues,
  UseFormSetError,
} from "react-hook-form";

interface ApiValidationError {
  fieldErrors?: Record<
    string,
    string
  >;
}

interface MapOptions<
  TValues extends FieldValues,
> {
  error:
    ApiValidationError;

  allowedFields:
    readonly FieldPath<
      TValues
    >[];

  setError:
    UseFormSetError<
      TValues
    >;
}

export function mapApiErrors<
  TValues extends FieldValues,
>({
  error,
  allowedFields,
  setError,
}: MapOptions<TValues>) {
  if (!error.fieldErrors) {
    return false;
  }

  const allowed =
    new Set<string>(
      allowedFields,
    );

  let mapped = false;
  let focusAssigned =
    false;

  for (const [
    field,
    message,
  ] of Object.entries(
    error.fieldErrors,
  )) {
    if (!allowed.has(field)) {
      continue;
    }

    const fieldPath =
      field as FieldPath<
        TValues
      >;

    setError(
      fieldPath,
      {
        type: "server",
        message,
      },
      {
        shouldFocus:
          !focusAssigned,
      },
    );

    focusAssigned = true;
    mapped = true;
  }

  return mapped;
}

This avoids reimplementing the mapping differently in every form.

18.9 Form Analytics

Useful analytics may include:

Form started
Step completed
Field error occurred
Draft restored
Upload failed
Form submitted
Form abandoned

Do not capture sensitive field values unnecessarily.

Bad:

analytics.track(
  "field_changed",
  {
    field: "password",
    value: password,
  },
);

Better:

analytics.track(
  "validation_error",
  {
    form:
      "registration",
    field:
      "password",
    errorCode:
      "TOO_SHORT",
  },
);

Never send passwords, complete document contents, or other sensitive form values into analytics systems.

18.10 Testing Strategy

A production form needs several testing layers.

Schema tests
→ Do validation rules work?

Component tests
→ Are errors displayed correctly?

Integration tests
→ Does submission map server errors?

Accessibility tests
→ Are labels and descriptions connected?

End-to-end tests
→ Can a real user complete the workflow?

Schema test example

import {
  describe,
  expect,
  it,
} from "vitest";

import {
  registerSchema,
} from "./register.schema";

describe(
  "registerSchema",
  () => {
    it(
      "rejects an invalid email",
      () => {
        const result =
          registerSchema
            .safeParse({
              username:
                "karthik",
              email:
                "invalid",
              password:
                "Password123",
            });

        expect(
          result.success,
        ).toBe(false);
      },
    );

    it(
      "normalizes the email",
      () => {
        const result =
          registerSchema
            .parse({
              username:
                "karthik",
              email:
                "KARTHIK@EXAMPLE.COM",
              password:
                "Password123",
            });

        expect(
          result.email,
        ).toBe(
          "karthik@example.com",
        );
      },
    );
  },
);

Component test example

import {
  render,
  screen,
} from "@testing-library/react";

import userEvent from "@testing-library/user-event";

import RegisterForm from "./RegisterForm";

it(
  "shows an email validation error",
  async () => {
    const user =
      userEvent.setup();

    render(
      <RegisterForm />,
    );

    await user.type(
      screen.getByLabelText(
        /email/i,
      ),
      "invalid",
    );

    await user.click(
      screen.getByRole(
        "button",
        {
          name:
            /create account/i,
        },
      ),
    );

    expect(
      await screen.findByText(
        /valid email/i,
      ),
    ).toBeInTheDocument();
  },
);

Test what the user sees and does.

Avoid testing private implementation details.

Modern Form Architecture Diagram

Page or route
      ↓
Feature form component
      ↓
React Hook Form
      ↓
Validation schema
      ↓
API function
      ↓
Backend endpoint
      ↓
Service layer
      ↓
Database

Supporting systems:
├── Draft storage
├── File storage
├── Analytics
├── Logging
├── Error monitoring
└── Toast notifications

Advantages of Modern Architecture

Clear responsibility boundaries
Reusable field components
Consistent accessibility
Testable schemas
Centralized API handling
Easier backend error mapping
Safer feature changes
Better team collaboration
Better monitoring and debugging

Disadvantages

More files
More architectural decisions
Can become overengineered for small forms
Abstractions require documentation
Generic components can become too complicated
Teams must maintain conventions
Shared layers may slow simple experimentation

Senior engineer tip

Do not create ten abstractions before building the first form.

A healthy evolution is:

Build one form
      ↓
Build the second form
      ↓
Identify real repetition
      ↓
Extract the repeated pattern
      ↓
Test the abstraction

Abstract repeated problems, not imagined future problems.

Why this evolved

Production architecture made forms maintainable, but the platform itself has also continued to evolve. React now supports form actions, Next.js can invoke server-side functions from forms, browsers provide stronger autofill and device capabilities, and AI systems can extract or generate form data. These changes are moving forms toward hybrid human-and-agent workflows.

Stage 19: The Future of Forms

For many years, web-form development moved in one direction:

More JavaScript
More client state
More frontend abstractions

Modern frameworks are now recovering useful capabilities from traditional HTML forms:

Native submission semantics
Progressive enhancement
Server-side mutation functions
Built-in pending states
Less manually written API plumbing

At the same time, AI is changing who—or what—fills the form.

The future is unlikely to eliminate forms completely.

Instead, forms will become:

More semantic
More server-connected
More adaptive
More multimodal
More automated
More privacy-sensitive

19.1 React Form Actions

React supports passing a function to a form's action prop.

<form action={saveProfile}>

This moves submission closer to native form semantics.

React also provides tools such as:

useActionState
useFormStatus
useOptimistic

React 19 introduced form Actions and related hooks for managing action state, pending submission, and optimistic updates.

Basic React action example

async function saveMessage(
  formData: FormData,
) {
  const message =
    formData.get("message");

  console.log(message);
}

export default function MessageForm() {
  return (
    <form action={saveMessage}>
      <label htmlFor="message">
        Message
      </label>

      <textarea
        id="message"
        name="message"
        required
      />

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

The form uses native name attributes to construct FormData.

`useFormStatus`

A child component can read the surrounding form submission state.

"use client";

import {
  useFormStatus,
} from "react-dom";

export function SubmitButton() {
  const {
    pending,
  } = useFormStatus();

  return (
    <button
      type="submit"
      disabled={pending}
    >
      {pending
        ? "Saving..."
        : "Save"}
    </button>
  );
}

useFormStatus() provides information about the latest surrounding form submission, including whether it is pending.

`useActionState`

useActionState() connects a form action to returned state.

"use client";

import {
  useActionState,
} from "react";

interface FormState {
  success: boolean;
  message: string;
}

const initialState:
  FormState = {
    success: false,
    message: "",
  };

async function submitContact(
  previousState:
    FormState,

  formData:
    FormData,
): Promise<FormState> {
  const email =
    String(
      formData.get("email") ??
        "",
    );

  if (!email.includes("@")) {
    return {
      success: false,
      message:
        "Enter a valid email address.",
    };
  }

  return {
    success: true,
    message:
      "Message submitted.",
  };
}

export default function ContactForm() {
  const [
    state,
    formAction,
    isPending,
  ] = useActionState(
    submitContact,
    initialState,
  );

  return (
    <form action={formAction}>
      <label htmlFor="email">
        Email
      </label>

      <input
        id="email"
        name="email"
        type="email"
      />

      <button
        type="submit"
        disabled={isPending}
      >
        {isPending
          ? "Submitting..."
          : "Submit"}
      </button>

      {state.message && (
        <p
          role={
            state.success
              ? "status"
              : "alert"
          }
        >
          {state.message}
        </p>
      )}
    </form>
  );
}

useActionState() returns the current action state, a dispatchable action, and a pending indicator.

Does this replace React Hook Form?

Not always.

Actions solve:

Submission lifecycle
Server invocation
Pending state
Returned action state
Progressive enhancement

React Hook Form solves:

Field registration
Client validation
Dirty fields
Touched fields
Dynamic arrays
Conditional values
Complex field control
Client-side form state

A form can use:

Simple server form
→ React Action only

Large interactive form
→ React Hook Form

Large interactive server form
→ React Hook Form + Server Action

The correct choice depends on interaction complexity.

19.2 Next.js App Router Forms

Next.js supports Server Actions—server-side functions that can be invoked by forms in Server or Client Components. The official Next.js forms guide describes them as Server Functions used to handle form submissions.

Complete Next.js Server Action example

Create:

app/register/actions.ts

"use server";

import { z } from "zod";

const registerSchema =
  z.object({
    username:
      z
        .string()
        .trim()
        .min(
          3,
          "Username must contain at least 3 characters.",
        ),

    email:
      z
        .string()
        .trim()
        .email(
          "Enter a valid email address.",
        ),
  });

export interface RegisterState {
  success: boolean;
  message: string;

  fieldErrors: {
    username?: string[];
    email?: string[];
  };
}

export async function registerAction(
  previousState:
    RegisterState,

  formData:
    FormData,
): Promise<RegisterState> {
  const result =
    registerSchema.safeParse({
      username:
        formData.get(
          "username",
        ),

      email:
        formData.get("email"),
    });

  if (!result.success) {
    return {
      success: false,

      message:
        "Correct the invalid fields.",

      fieldErrors:
        result.error
          .flatten()
          .fieldErrors,
    };
  }

  /*
   * Authentication and authorization
   * must still be checked here where
   * appropriate.
   */

  const emailExists =
    result.data.email ===
    "existing@example.com";

  if (emailExists) {
    return {
      success: false,

      message:
        "This email is already registered.",

      fieldErrors: {
        email: [
          "This email is already registered.",
        ],
      },
    };
  }

  /*
   * Insert the user through the
   * service or repository layer.
   */

  return {
    success: true,

    message:
      "Registration successful.",

    fieldErrors: {},
  };
}

Create:

app/register/RegisterForm.tsx

"use client";

import {
  useActionState,
} from "react";

import {
  registerAction,
} from "./actions";

import type {
  RegisterState,
} from "./actions";

const initialState:
  RegisterState = {
    success: false,
    message: "",
    fieldErrors: {},
  };

export default function RegisterForm() {
  const [
    state,
    formAction,
    isPending,
  ] = useActionState(
    registerAction,
    initialState,
  );

  return (
    <form action={formAction}>
      <div className="field">
        <label htmlFor="username">
          Username
        </label>

        <input
          id="username"
          name="username"
          required
          aria-invalid={Boolean(
            state.fieldErrors
              .username,
          )}
          aria-describedby={
            state.fieldErrors
              .username
              ? "username-error"
              : undefined
          }
        />

        {state.fieldErrors
          .username?.map(
          (message) => (
            <p
              key={message}
              id="username-error"
              className="error"
            >
              {message}
            </p>
          ),
        )}
      </div>

      <div className="field">
        <label htmlFor="email">
          Email
        </label>

        <input
          id="email"
          name="email"
          type="email"
          required
          autoComplete="email"
          aria-invalid={Boolean(
            state.fieldErrors
              .email,
          )}
          aria-describedby={
            state.fieldErrors
              .email
              ? "email-error"
              : undefined
          }
        />

        {state.fieldErrors
          .email?.map(
          (message) => (
            <p
              key={message}
              id="email-error"
              className="error"
            >
              {message}
            </p>
          ),
        )}
      </div>

      {state.message && (
        <p
          role={
            state.success
              ? "status"
              : "alert"
          }
        >
          {state.message}
        </p>
      )}

      <button
        type="submit"
        disabled={isPending}
      >
        {isPending
          ? "Registering..."
          : "Register"}
      </button>
    </form>
  );
}

Next.js states that forms invoking Server Actions can support progressive-enhancement behavior, including submission before full client hydration in supported arrangements.

Server Actions are still public mutation boundaries

Do not think:

Server Action
= automatically secure

A Server Action must still perform:

Authentication
Authorization
Runtime validation
Rate limiting where appropriate
Ownership checks
Safe database operations

Next.js security guidance treats Server Actions as externally reachable mutation boundaries and recommends validating authorization and data access inside the server-side operation.

19.3 Progressive Enhancement Returns

The earliest HTML forms worked without JavaScript.

Modern Server Actions partly return to that model:

Semantic HTML form
        ↓
Server-side operation
        ↓
Enhanced by React when available

This is not a return to primitive websites.

It is a combination:

Native browser behavior
+
Modern server rendering
+
Selective client interaction

Forms with function-based actions can support submission before the client bundle has fully loaded in compatible React Server Function setups.

19.4 Native Browser Improvements

Modern applications sometimes rebuild features browsers already understand.

Browsers provide:

Input types
Constraint validation
Date and time controls
Password-manager integration
Autofill
Address completion hints
File selection
Camera capture hints
Mobile keyboard hints
Credential-management integrations

The autocomplete attribute can describe information such as:

<input
  autocomplete="given-name"
/>

<input
  autocomplete="family-name"
/>

<input
  autocomplete="email"
/>

<input
  autocomplete="shipping street-address"
/>

<input
  autocomplete="shipping postal-code"
/>

These tokens help browsers and password managers understand field meaning and offer appropriate saved values.

Future native form direction

Over the next decade, browsers will likely become better at:

Recognizing semantic field purpose
Prefilling structured identity information
Using passkeys and secure credentials
Validating common formats
Integrating camera and document capture
Preserving drafts
Supporting accessibility preferences

The strongest future forms will use browser semantics instead of fighting them.

19.5 AI-Assisted Form Completion

Traditional autofill matches known fields:

email
address
phone
name

AI-assisted completion can infer values from broader context.

Example:

User uploads a resume
        ↓
AI extracts:
├── Name
├── Email
├── Skills
├── Education
└── Work experience
        ↓
Form is prefilled
        ↓
User reviews and confirms

The correct pattern is:

AI suggests
Human reviews
Application validates
Server verifies

Not:

AI guessed
        ↓
Automatically trusted

Suggested-value interface

interface SuggestedFieldProps {
  label: string;
  currentValue: string;
  suggestedValue?: string;
  onAccept:
    (value: string) => void;
}

export default function SuggestedField({
  label,
  currentValue,
  suggestedValue,
  onAccept,
}: SuggestedFieldProps) {
  return (
    <section>
      <p>
        <strong>
          {label}
        </strong>
      </p>

      <p>
        Current:{" "}
        {currentValue ||
          "Not entered"}
      </p>

      {suggestedValue && (
        <div>
          <p>
            Suggested:{" "}
            {suggestedValue}
          </p>

          <button
            type="button"
            onClick={() => {
              onAccept(
                suggestedValue,
              );
            }}
          >
            Use suggestion
          </button>
        </div>
      )}
    </section>
  );
}

Use it with React Hook Form:

<SuggestedField
  label="Current role"
  currentValue={
    getValues(
      "currentRole",
    )
  }
  suggestedValue={
    resumeResult
      ?.currentRole
  }
  onAccept={(value) => {
    setValue(
      "currentRole",
      value,
      {
        shouldDirty: true,
        shouldValidate: true,
      },
    );
  }}
/>

The user controls whether the suggestion is accepted.

19.6 AI-Generated Validation

AI could assist developers by proposing validation rules.

Example input:

Build a candidate registration form.
Username must be unique.
Password needs at least 12 characters.
Applicants must provide either LinkedIn or a portfolio.

AI may generate:

const schema = z
  .object({
    username:
      z.string().min(3),

    password:
      z.string().min(12),

    linkedInUrl:
      z.string().url().optional(),

    portfolioUrl:
      z.string().url().optional(),
  })
  .refine(
    (values) =>
      values.linkedInUrl ||
      values.portfolioUrl,
    {
      message:
        "Provide LinkedIn or a portfolio.",
    },
  );

But generated validation must be reviewed.

AI may:

Misunderstand the requirement
Create an incorrect regex
Forget localization
Reject valid international data
Encode biased assumptions
Generate only frontend checks
Miss authorization or database requirements

AI can accelerate implementation.

It cannot own the final business policy.

19.7 Voice-Based Form Filling

A user may say:

My name is Karthik. My email is karthik@example.com. I am applying for a frontend role.

The application can convert speech into text, extract fields, and ask for confirmation.

Voice
  ↓
Speech recognition
  ↓
Text transcript
  ↓
Field extraction
  ↓
User confirmation
  ↓
Validation

The Web Speech API includes speech recognition and speech synthesis interfaces, although speech-recognition support remains inconsistent across major browsers and requires compatibility checks.

Simplified voice-input example

import {
  useState,
} from "react";

interface SpeechRecognitionEventLike {
  results: {
    [index: number]: {
      [index: number]: {
        transcript: string;
      };
    };
  };
}

export default function VoiceField() {
  const [
    value,
    setValue,
  ] = useState("");

  const [
    listening,
    setListening,
  ] = useState(false);

  function startListening() {
    const SpeechRecognition =
      (
        window as typeof window & {
          webkitSpeechRecognition?:
            new () => {
              lang: string;
              interimResults: boolean;
              start: () => void;
              onresult:
                (
                  event:
                    SpeechRecognitionEventLike,
                ) => void;
              onend:
                () => void;
              onerror:
                () => void;
            };
        }
      )
        .webkitSpeechRecognition;

    if (!SpeechRecognition) {
      alert(
        "Voice input is not supported in this browser.",
      );

      return;
    }

    const recognition =
      new SpeechRecognition();

    recognition.lang =
      "en-IN";

    recognition
      .interimResults = false;

    recognition.onresult =
      (event) => {
        const transcript =
          event.results[0][0]
            .transcript;

        setValue(transcript);
      };

    recognition.onend =
      () => {
        setListening(false);
      };

    recognition.onerror =
      () => {
        setListening(false);
      };

    setListening(true);
    recognition.start();
  }

  return (
    <div className="field">
      <label htmlFor="bio">
        Professional summary
      </label>

      <textarea
        id="bio"
        value={value}
        onChange={(event) => {
          setValue(
            event.target.value,
          );
        }}
      />

      <button
        type="button"
        onClick={startListening}
        disabled={listening}
      >
        {listening
          ? "Listening..."
          : "Fill using voice"}
      </button>
    </div>
  );
}

This example is intentionally simplified.

Production voice input needs:

Permission handling
Browser compatibility handling
Language selection
Transcript review
Error correction
Clear recording indication
Privacy disclosure
A non-voice alternative

19.8 OCR and Document Auto-Fill

OCR converts document images into machine-readable text.

A possible onboarding workflow:

Capture identity document
        ↓
Upload image
        ↓
OCR extracts text
        ↓
Parser identifies fields
        ↓
Form is prefilled
        ↓
User verifies every value

Mobile file inputs may request camera capture through attributes such as accept and capture, although capture support is not consistent across every major browser.

Example:

<input
  type="file"
  accept="image/*"
  capture="environment"
/>

OCR result-review example

interface ExtractedIdentity {
  fullName?: string;
  documentNumber?: string;
  dateOfBirth?: string;
}

interface ReviewProps {
  extracted:
    ExtractedIdentity;

  onAccept:
    (
      values:
        ExtractedIdentity,
    ) => void;
}

export default function OcrReview({
  extracted,
  onAccept,
}: ReviewProps) {
  return (
    <section>
      <h2>
        Review extracted
        information
      </h2>

      <dl>
        <dt>Full name</dt>
        <dd>
          {extracted.fullName ??
            "Not detected"}
        </dd>

        <dt>Document number</dt>
        <dd>
          {
            extracted
              .documentNumber ??
            "Not detected"
          }
        </dd>

        <dt>Date of birth</dt>
        <dd>
          {
            extracted
              .dateOfBirth ??
            "Not detected"
          }
        </dd>
      </dl>

      <p>
        Check every value against
        your document before
        continuing.
      </p>

      <button
        type="button"
        onClick={() => {
          onAccept(extracted);
        }}
      >
        Use these values
      </button>
    </section>
  );
}

OCR output must not be silently treated as correct.

Common OCR errors include:

0 confused with O
1 confused with I
Incorrect names
Wrong date formats
Missing spaces
Cropped text
Incorrect language recognition

19.9 Conversational Forms

Instead of displaying 30 inputs, a conversational interface may ask one question at a time.

Assistant:
What role are you applying for?

User:
Frontend developer.

Assistant:
How many years of experience do you have?

User:
Two.

Assistant:
Would you like to upload your resume?

Internally, it may still build structured form data:

{
  role:
    "Frontend developer",

  yearsOfExperience:
    2,

  resume:
    File | null
}

Benefits

Feels natural for some users
Can explain confusing questions
Can ask relevant follow-ups
Supports voice and text
Can hide irrelevant questions
Can help users who struggle with complex forms

Risks

Harder to review all information
Slower for expert users
Conversation history may hide errors
Accessibility must be carefully tested
Users may not know what will be asked
AI can misinterpret answers
Final structured confirmation is still required

Best hybrid pattern

Conversation collects data
        ↓
Structured review page
        ↓
User edits fields
        ↓
Explicit confirmation
        ↓
Final submission

The conversation assists completion.

The structured form preserves clarity and control.

19.10 Agentic AI Completing Forms

An AI agent may eventually complete multi-site workflows for a user.

Example:

User:
Apply to suitable frontend jobs.

Agent:
1. Reads approved profile
2. Finds matching roles
3. Prepares application answers
4. Requests approval
5. Submits approved applications
6. Tracks responses

This changes the form's consumer.

Historically:

Human
  ↓
Form

Future:

Human
  ↓
Authorized agent
  ↓
Form or structured API

Forms may therefore need to support:

Human users
Password managers
Browser autofill
Accessibility tools
Trusted automated agents
Structured machine-readable submission

Agent-safe form architecture

A future-ready system may expose:

Visual form
        +
Semantic HTML fields
        +
Documented validation schema
        +
Structured API
        +
Explicit authorization

Agents should not need to guess meaning from visual position.

Field semantics should be clear:

<input
  name="email"
  type="email"
  autocomplete="email"
/>

instead of:

<input
  name="field_17"
/>

19.11 Privacy Implications

AI-enhanced forms may process:

Identity data
Employment history
Documents
Voice recordings
Location
Financial information
Personal preferences

Production systems should apply:

Data minimization
Purpose limitation
User consent
Secure transport
Access control
Retention limits
Encryption
Audit logging
Deletion workflows

Ask:

Is this data necessary?
Where is it processed?
Is it sent to an external AI provider?
How long is it retained?
Can the user correct it?
Can the user delete it?
Is it used for model training?
Can staff access it?
Is the result explainable?

19.12 Security Implications

AI-generated or agent-submitted forms introduce new threats:

Fabricated data
Prompt injection in uploaded documents
Automated spam
Mass submissions
Identity misuse
Hidden malicious instructions
Unauthorized agent actions
Sensitive-data leakage

Security controls may include:

Authentication
Authorization
Rate limiting
File scanning
Schema validation
Database constraints
Agent scopes
Explicit user approval
Audit logs
Idempotency keys
Risk-based review

An AI agent should not receive unlimited permission merely because it is convenient.

19.13 Accessibility Implications

AI may improve accessibility through:

Voice entry
Plain-language explanations
Automatic translation
Error correction suggestions
Document extraction
Personalized input methods

It may also create new barriers:

Inaccurate voice recognition
Chat interfaces that hide form structure
Dynamic updates that are not announced
Suggestions that cannot be reached by keyboard
Unclear automated decisions
Interfaces requiring speech

The rule should be:

AI adds another path
It does not remove accessible
traditional paths

Users should still be able to:

Type instead of speak
Upload instead of use a camera
Review extracted information
Correct AI suggestions
Complete the form without AI
Reach every action by keyboard

What Production Forms May Look Like in 5–10 Years

The following is a prediction, not a guaranteed roadmap.

Prediction 1: Fewer manually written API submission handlers

More frameworks will support:

<form action={serverFunction}>

Developers will still validate and authorize on the server, but less code may be needed to connect a basic form to a mutation.

Prediction 2: Hybrid client-and-server validation

Forms will increasingly use:

Browser validation
        +
Client schema validation
        +
Server action validation
        +
Database constraints

Each layer will have a clear responsibility.

Prediction 3: Forms generated from schemas

One schema may produce:

TypeScript types
Runtime validation
API documentation
Default values
Form fields
Error messages
Test cases

However, fully generated UI will still need human design review because the same data schema can support many different user experiences.

Prediction 4: Document-first onboarding

Instead of entering 30 fields manually:

Upload approved document
        ↓
Extract structured data
        ↓
Review highlighted uncertainty
        ↓
Confirm

Users may edit only fields the system could not confidently extract.

Prediction 5: Confidence-aware AI suggestions

AI-generated values may include confidence information:

{
  field:
    "currentRole",

  value:
    "Frontend Developer",

  confidence:
    0.94,

  source:
    "resume-page-1"
}

Low-confidence fields will require explicit review.

Prediction 6: Conversational and visual forms will coexist

Chat will not replace every form.

A likely interface:

Conversation
→ Helps collect and explain

Structured form
→ Supports review and correction

Summary screen
→ Supports explicit confirmation

Prediction 7: Agents will prefer APIs over visual automation

Visual browser automation is fragile.

A more reliable future is:

Authorized agent
        ↓
Documented structured action
        ↓
Validated server operation
        ↓
Auditable result

Applications may expose agent-readable capabilities while retaining human-facing forms.

Prediction 8: Stronger consent and auditability

Users may see:

Your assistant wants to:

✓ Read your approved profile
✓ Fill contact information
✓ Upload your selected resume
✗ Cannot submit without approval

Actions may produce logs:

Agent filled form
User edited salary expectation
User approved submission
Application submitted at 14:32

Prediction 9: Forms will become more adaptive

A form may adjust based on:

User role
Previous answers
Device
Accessibility preferences
Locale
Risk level
Available documents
Existing verified information

Adaptive does not mean unpredictable.

The form must still explain why information is requested.

Prediction 10: Semantic HTML will become more valuable

As browsers, password managers, assistive technology, and AI agents interact with forms, correct semantics will matter more—not less.

<label for="email">
  Email
</label>

<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
/>

is useful to:

Humans
Browsers
Screen readers
Password managers
Testing tools
Automated agents

A Future Form Architecture

User or authorized agent
          ↓
Semantic adaptive interface
          ↓
Client-side schema validation
          ↓
Server Action or API
          ↓
Authentication and authorization
          ↓
Business-rule validation
          ↓
Database transaction
          ↓
Audit log
          ↓
Accessible confirmation

Optional assistance:

Voice
OCR
AI suggestions
Conversational guidance
Document extraction
Autosave
Offline draft

None of these optional features should bypass the trusted server pipeline.

Final Best-Practices Checklist

HTML Foundation

Use a real <form>.
Use native inputs where possible.
Give every field a meaningful name.
Connect labels using htmlFor and id.
Use correct input types.
Add useful autocomplete tokens.
Use explicit button types.

Validation

Validate on the frontend for user experience.
Validate again on the server.
Use database constraints for integrity.
Separate structural validation from business rules.
Return consistent error codes and field paths.
Never trust a TypeScript assertion as runtime validation.

React Hook Form

Provide complete default values.
Prefer register() for native inputs.
Use Controller only when controlled integration is required.
Use useFieldArray() for dynamic arrays.
Watch only the values required for rendering.
Map backend field errors through setError().
Use root errors for form-wide failures.

Accessibility

Keep visible labels.
Associate hints and errors.
Use aria-invalid after validation.
Preserve visible keyboard focus.
Group related choices using fieldset and legend.
Focus the first invalid field or error summary after submission.
Do not rely only on color.
Do not make AI or voice the only completion path.

Performance

Keep rapidly changing state close to where it is used.
Avoid watching the complete form unnecessarily.
Choose validation timing deliberately.
Debounce asynchronous checks.
Cancel stale requests.
Profile before adding memoization.
Measure user-visible delays rather than counting renders alone.

Security

Treat all client input as untrusted.
Validate uploaded files on the server.
Do not store sensitive drafts carelessly.
Protect mutations with authentication and authorization.
Rate-limit abuse-sensitive operations.
Avoid exposing internal errors.
Audit automated or agent-driven submissions.
Require explicit approval for high-impact actions.

Final Series Summary

Web forms began as a built-in browser feature.

<form
  action="/register"
  method="POST"
>

The browser collected values, sent a request, and loaded a new page.

Then validation moved into HTML:

<input
  type="email"
  required
  minlength="3"
/>

JavaScript added custom behavior:

event.preventDefault();

AJAX removed full-page refreshes:

await fetch(
  "/api/register",
);

React made UI state declarative:

<input
  value={email}
  onChange={handleChange}
/>

Large controlled forms created boilerplate:

values
errors
touched
dirty
loading
validation

Form libraries organized that complexity.

React Hook Form reduced value-driven parent updates:

<input
  {...register("email")}
/>

Zod centralized runtime validation:

const schema =
  z.object({
    email:
      z.string().email(),
  });

The resolver connected the schema to the form:

useForm({
  resolver:
    zodResolver(schema),
});

The backend protected the trusted boundary:

schema.safeParse(
  request.body,
);

Server errors returned to matching fields:

setError(
  "email",
  {
    type: "server",
    message:
      "Email already exists.",
  },
);

Enterprise forms introduced workflows:

Steps
Dynamic arrays
Uploads
Autosave
Drafts
Optimistic UI

Modern React and Next.js are reconnecting forms with server-side actions:

<form action={serverAction}>

And future forms will increasingly accept information through:

Typing
Autofill
Documents
Voice
Conversation
Authorized AI agents

But the fundamental engineering principles will remain the same:

Use semantic HTML.

Make errors understandable.

Treat client data as untrusted.

Keep users in control.

Validate at every trust boundary.

Design accessibility from the beginning.

Use abstractions only when they
remove real complexity.

A modern form is not simply a collection of inputs.

It is a carefully designed communication system between:

The user
The browser
The frontend
The backend
The database
Assistive technology
And increasingly, AI agents

Understanding this evolution means you no longer need to memorize React Hook Form as a mysterious library.

You understand the problems it inherited, the trade-offs it makes, and the reason the web-form ecosystem evolved in this direction.

The Evolution of Web Forms — Part 4

Karthik Reddy — Mon, 24 Aug 2026 06:43:25 +0000

The Evolution of Web Forms — Part 4: Server Validation, Backend Errors, Accessibility, and Performance

In Part 3, we created a modern frontend form using:

React Hook Form
        +
       Zod
        +
    TypeScript

That form could:

Register fields
Validate data
Display field errors
Track dirty and touched fields
Prevent invalid submission
Transform email addresses
Handle loading state
Receive backend errors through setError()

However, a production form cannot stop at frontend validation.

Frontend code runs on the user's device.

The user controls:

The browser
The JavaScript
The request body
The request headers
The API client
The timing of requests

A request does not have to come from your React application.

Someone can directly call your backend using:

Another frontend
A mobile application
An automated script
An API-testing tool
A modified browser request

Therefore, the server must treat every request as untrusted.

This part covers:

Server-side validation with Express and Zod
Mapping backend errors into React Hook Form
Building accessible production forms
Understanding form performance and rerenders

Stage 13: Server-Side Validation

Frontend validation exists mainly to improve the user experience.

Backend validation exists to protect the application and preserve correct data.

These responsibilities overlap, but they are not identical.

Frontend validation
├── Fast feedback
├── Better user experience
├── Prevent obvious mistakes
└── Reduce unnecessary requests

Backend validation
├── Enforce trusted rules
├── Protect the database
├── Reject malicious requests
├── Enforce authorization
└── Preserve data integrity

A user can bypass frontend validation completely.

How frontend validation can be bypassed

Suppose your React form requires:

Username: at least 3 characters
Email: valid format
Password: at least 8 characters

Your frontend may correctly reject:

{
  "username": "",
  "email": "hello",
  "password": "12"
}

But someone can send this object directly to your API:

POST /api/auth/register
Content-Type: application/json

{
  "username": "",
  "email": "hello",
  "password": "12"
}

Your React application is not involved.

The request goes directly to Express.

Custom API client
       ↓
POST /api/auth/register
       ↓
Express server

If the backend trusts the frontend, invalid data may enter the database.

The backend validation pipeline

A production registration request commonly passes through several layers.

Incoming HTTP request
        ↓
Parse JSON body
        ↓
Structural validation
        ↓
Normalize selected values
        ↓
Business-rule validation
        ↓
Database checks
        ↓
Create user
        ↓
Return safe response

Each layer answers a different question.

Structural validation

Structural validation checks the shape and basic format of the request.

Examples:

Is username a string?
Is email present?
Does email have a valid format?
Is password long enough?

Zod is useful here.

Business-rule validation

Business validation checks application-specific rules.

Examples:

Is the username reserved?
Is registration currently allowed?
Can this organization add more users?
Is the user old enough for this service?

These rules may require service logic beyond a schema.

Database validation

Some rules require querying the database.

Examples:

Does the email already exist?
Is the username already taken?
Is the invitation token valid?
Has this reset token already been used?

Zod cannot answer these questions by itself.

Authorization validation

Authorization asks whether the current user is permitted to perform the operation.

Examples:

Can this user edit this profile?
Can this manager create another employee?
Can this member delete this organization?

A valid request body does not imply that the requester has permission.

Shared validation schema

In a TypeScript monorepo, structural validation can often be shared.

apps/
├── web/
└── api/

packages/
└── validation/
    └── auth.schemas.ts

Create:

packages/validation/auth.schemas.ts

import { z } from "zod";

export const registerSchema = z.object({
  username: z
    .string()
    .trim()
    .min(1, "Username is required.")
    .min(
      3,
      "Username must contain at least 3 characters.",
    )
    .max(
      20,
      "Username cannot exceed 20 characters.",
    )
    .regex(
      /^[A-Za-z0-9_]+$/,
      "Use only letters, numbers, and underscores.",
    ),

  displayName: z
    .string()
    .trim()
    .min(1, "Display name is required.")
    .min(
      2,
      "Display name must contain at least 2 characters.",
    )
    .max(
      50,
      "Display name cannot exceed 50 characters.",
    ),

  email: z
    .string()
    .trim()
    .min(1, "Email is required.")
    .email("Enter a valid email address.")
    .transform((email) => email.toLowerCase()),

  password: z
    .string()
    .min(1, "Password is required.")
    .min(
      8,
      "Password must contain at least 8 characters.",
    )
    .max(
      72,
      "Password cannot exceed 72 characters.",
    ),

  acceptTerms: z.literal(true, {
    message: "You must accept the terms.",
  }),
});

export type RegisterInput = z.input<
  typeof registerSchema
>;

export type RegisterOutput = z.output<
  typeof registerSchema
>;

The frontend can use this schema through zodResolver().

The backend can use the same schema through safeParse().

                   registerSchema
                    /           \
                   /             \
          React frontend       Express backend
          zodResolver()        safeParse()

Sharing the schema reduces accidental differences between frontend and backend structural rules.

It does not remove the backend's responsibility to validate.

Why use `safeParse()` on the server?

The backend receives data of an unknown shape.

Even when TypeScript says:

request.body

exists, the actual runtime value may be anything.

null

[]

{
  "email": 123
}

{
  "unexpected": "value"
}

Use:

const result = registerSchema.safeParse(
  request.body,
);

The result has two possible forms.

Success
├── success: true
└── data: validated and transformed values

Failure
├── success: false
└── error: validation details

Designing a consistent API error response

The frontend should not need to guess the structure of an error.

A useful error response may contain:

interface ApiErrorResponse {
  success: false;
  code: string;
  message: string;
  field?: string;
  fieldErrors?: Record<string, string>;
}

Each property has a role.

success
→ Indicates request failure

code
→ Stable machine-readable identifier

message
→ Human-readable explanation

field
→ One field related to the failure

fieldErrors
→ Multiple field-level failures

Example:

{
  "success": false,
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "An account with this email already exists."
}

The frontend can use code for logic and message for display.

Do not make frontend logic depend entirely on exact English sentences.

Bad:

if (
  error.message ===
  "An account with this email already exists."
) {
  // ...
}

Better:

if (
  error.code ===
  "EMAIL_ALREADY_EXISTS"
) {
  // ...
}

Messages can change because of:

Wording improvements
Translation
Product changes
Localization

Stable error codes are safer for application logic.

Complete Express 5 backend

Create the following structure:

server/
├── src/
│   ├── app.ts
│   ├── errors/
│   │   └── ApiError.ts
│   ├── middleware/
│   │   ├── errorHandler.ts
│   │   └── validate.ts
│   ├── routes/
│   │   └── auth.routes.ts
│   ├── schemas/
│   │   └── auth.schemas.ts
│   └── services/
│       └── auth.service.ts
├── package.json
└── tsconfig.json

Install the dependencies:

npm install express zod bcrypt
npm install --save-dev typescript tsx \
  @types/express @types/node @types/bcrypt

`src/schemas/auth.schemas.ts`

import { z } from "zod";

export const registerSchema = z.object({
  username: z
    .string()
    .trim()
    .min(1, "Username is required.")
    .min(
      3,
      "Username must contain at least 3 characters.",
    )
    .max(
      20,
      "Username cannot exceed 20 characters.",
    )
    .regex(
      /^[A-Za-z0-9_]+$/,
      "Use only letters, numbers, and underscores.",
    ),

  displayName: z
    .string()
    .trim()
    .min(1, "Display name is required.")
    .min(
      2,
      "Display name must contain at least 2 characters.",
    )
    .max(
      50,
      "Display name cannot exceed 50 characters.",
    ),

  email: z
    .string()
    .trim()
    .min(1, "Email is required.")
    .email("Enter a valid email address.")
    .transform((email) => email.toLowerCase()),

  password: z
    .string()
    .min(1, "Password is required.")
    .min(
      8,
      "Password must contain at least 8 characters.",
    )
    .max(
      72,
      "Password cannot exceed 72 characters.",
    ),
});

export type RegisterInput = z.input<
  typeof registerSchema
>;

export type RegisterOutput = z.output<
  typeof registerSchema
>;

`src/errors/ApiError.ts`

export interface ApiErrorDetails {
  code: string;
  field?: string;
  fieldErrors?: Record<string, string>;
}

export default class ApiError extends Error {
  readonly statusCode: number;
  readonly code: string;
  readonly field?: string;
  readonly fieldErrors?: Record<
    string,
    string
  >;

  constructor(
    statusCode: number,
    message: string,
    details: ApiErrorDetails,
  ) {
    super(message);

    this.name = "ApiError";
    this.statusCode = statusCode;
    this.code = details.code;
    this.field = details.field;
    this.fieldErrors =
      details.fieldErrors;

    Error.captureStackTrace?.(
      this,
      ApiError,
    );
  }
}

`src/middleware/validate.ts`

import type {
  NextFunction,
  Request,
  RequestHandler,
  Response,
} from "express";

import type {
  ZodType,
} from "zod";

import ApiError from "../errors/ApiError";

function createFieldErrors(
  issues: Array<{
    path: PropertyKey[];
    message: string;
  }>,
): Record<string, string> {
  const fieldErrors: Record<
    string,
    string
  > = {};

  for (const issue of issues) {
    const fieldPath = issue.path.join(".");

    if (
      fieldPath &&
      !fieldErrors[fieldPath]
    ) {
      fieldErrors[fieldPath] =
        issue.message;
    }
  }

  return fieldErrors;
}

export function validateBody<T>(
  schema: ZodType<T>,
): RequestHandler {
  return (
    request: Request,
    _response: Response,
    next: NextFunction,
  ) => {
    const result = schema.safeParse(
      request.body,
    );

    if (!result.success) {
      const fieldErrors =
        createFieldErrors(
          result.error.issues,
        );

      next(
        new ApiError(
          400,
          "Please correct the invalid fields.",
          {
            code: "VALIDATION_ERROR",
            fieldErrors,
          },
        ),
      );

      return;
    }

    /*
     * Replace the untrusted request body with
     * Zod's validated and transformed output.
     */
    request.body = result.data;

    next();
  };
}

The middleware replaces:

request.body

with:

result.data

That matters because Zod may normalize the values.

For example:

"  USER@EXAMPLE.COM "
          ↓
"user@example.com"

The service receives validated output rather than the original untrusted object.

Why convert Zod issues into field errors?

Zod issues may resemble:

[
  {
    path: ["email"],
    message:
      "Enter a valid email address.",
  },
  {
    path: ["password"],
    message:
      "Password must contain at least 8 characters.",
  },
]

The frontend usually wants:

{
  email:
    "Enter a valid email address.",

  password:
    "Password must contain at least 8 characters.",
}

The conversion creates an API format that is easier for any frontend to consume.

`src/services/auth.service.ts`

The following example uses an in-memory array so that it can run without a database.

A production application should replace this repository logic with a real database and a unique constraint.

import bcrypt from "bcrypt";

import ApiError from "../errors/ApiError";

import type {
  RegisterOutput,
} from "../schemas/auth.schemas";

interface StoredUser {
  id: string;
  username: string;
  displayName: string;
  email: string;
  hashedPassword: string;
}

interface PublicUser {
  id: string;
  username: string;
  displayName: string;
  email: string;
}

const users: StoredUser[] = [
  {
    id: crypto.randomUUID(),
    username: "existing_user",
    displayName: "Existing User",
    email: "existing@example.com",
    hashedPassword:
      "$2b$10$demonstrationHash",
  },
];

function findUserByEmail(
  email: string,
): StoredUser | undefined {
  return users.find(
    (user) => user.email === email,
  );
}

function findUserByUsername(
  username: string,
): StoredUser | undefined {
  const normalizedUsername =
    username.toLowerCase();

  return users.find(
    (user) =>
      user.username.toLowerCase() ===
      normalizedUsername,
  );
}

export async function registerUser(
  input: RegisterOutput,
): Promise<PublicUser> {
  const existingEmailUser =
    findUserByEmail(input.email);

  if (existingEmailUser) {
    throw new ApiError(
      409,
      "An account with this email already exists.",
      {
        code: "EMAIL_ALREADY_EXISTS",
        field: "email",
      },
    );
  }

  const existingUsernameUser =
    findUserByUsername(
      input.username,
    );

  if (existingUsernameUser) {
    throw new ApiError(
      409,
      "This username is already taken.",
      {
        code: "USERNAME_ALREADY_EXISTS",
        field: "username",
      },
    );
  }

  /*
   * Never store the original password.
   * Store a password hash.
   */
  const hashedPassword =
    await bcrypt.hash(
      input.password,
      12,
    );

  const user: StoredUser = {
    id: crypto.randomUUID(),
    username: input.username,
    displayName: input.displayName,
    email: input.email,
    hashedPassword,
  };

  users.push(user);

  return {
    id: user.id,
    username: user.username,
    displayName: user.displayName,
    email: user.email,
  };
}

Why the service checks uniqueness

Zod can validate:

email has a valid structure

Zod cannot determine:

email is absent from the database

The database or repository must answer that question.

Schema validation
        ↓
Email format is valid
        ↓
Repository query
        ↓
Does email already exist?

A database unique constraint is still necessary

This code is not sufficient by itself:

const existingUser =
  await findUserByEmail(email);

if (existingUser) {
  throw new Error(
    "Email already exists",
  );
}

await createUser(input);

Two requests may execute concurrently:

Request A checks email
→ not found

Request B checks email
→ not found

Request A inserts user
Request B inserts user

The database should enforce uniqueness.

Conceptually:

CREATE UNIQUE INDEX users_email_unique
ON users (email);

The service may perform a friendly pre-check, but it should also handle the database's unique-constraint error.

Application check
→ Better error message

Database constraint
→ Final integrity guarantee

`src/routes/auth.routes.ts`

import {
  Router,
} from "express";

import {
  registerSchema,
} from "../schemas/auth.schemas";

import {
  validateBody,
} from "../middleware/validate";

import {
  registerUser,
} from "../services/auth.service";

const authRouter = Router();

authRouter.post(
  "/register",
  validateBody(registerSchema),
  async (request, response) => {
    const user = await registerUser(
      request.body,
    );

    response.status(201).json({
      success: true,
      message:
        "Registration successful. Check your email to verify your account.",
      data: {
        user,
      },
    });
  },
);

export default authRouter;

In Express 5, rejected promises from async route handlers are forwarded to error-handling middleware, so errors thrown by the awaited service can reach the central error handler without manually wrapping every route in try/catch.

`src/middleware/errorHandler.ts`

import type {
  ErrorRequestHandler,
} from "express";

import ApiError from "../errors/ApiError";

export const errorHandler:
  ErrorRequestHandler = (
    error,
    _request,
    response,
    _next,
  ) => {
    if (error instanceof ApiError) {
      response
        .status(error.statusCode)
        .json({
          success: false,
          code: error.code,
          message: error.message,
          field: error.field,
          fieldErrors:
            error.fieldErrors,
        });

      return;
    }

    /*
     * Log the full internal error securely.
     * Do not send its stack trace to clients.
     */
    console.error(error);

    response.status(500).json({
      success: false,
      code: "INTERNAL_SERVER_ERROR",
      message:
        "An unexpected error occurred.",
    });
  };

`src/app.ts`

import express from "express";

import authRouter from "./routes/auth.routes";

import {
  errorHandler,
} from "./middleware/errorHandler";

const app = express();
const port = 3000;

app.use(
  express.json({
    limit: "100kb",
  }),
);

app.use(
  "/api/auth",
  authRouter,
);

app.use(
  (
    _request,
    response,
  ) => {
    response.status(404).json({
      success: false,
      code: "ROUTE_NOT_FOUND",
      message:
        "The requested resource was not found.",
    });
  },
);

/*
 * Error middleware must be registered after
 * routes and normal middleware.
 */
app.use(errorHandler);

const server = app.listen(
  port,
  (error) => {
    if (error) {
      throw error;
    }

    console.log(
      `API running on port ${port}`,
    );
  },
);

export default server;

Successful registration response

{
  "success": true,
  "message": "Registration successful. Check your email to verify your account.",
  "data": {
    "user": {
      "id": "generated-user-id",
      "username": "karthik_2005",
      "displayName": "Karthik",
      "email": "karthik@example.com"
    }
  }
}

Notice that the response does not return:

password
hashedPassword

Sensitive internal values should not be included in the public response.

Structural validation response

Request:

{
  "username": "a",
  "displayName": "",
  "email": "invalid-email",
  "password": "12"
}

Response:

{
  "success": false,
  "code": "VALIDATION_ERROR",
  "message": "Please correct the invalid fields.",
  "fieldErrors": {
    "username": "Username must contain at least 3 characters.",
    "displayName": "Display name is required.",
    "email": "Enter a valid email address.",
    "password": "Password must contain at least 8 characters."
  }
}

Duplicate email response

{
  "success": false,
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "An account with this email already exists."
}

Username already taken response

{
  "success": false,
  "code": "USERNAME_ALREADY_EXISTS",
  "field": "username",
  "message": "This username is already taken."
}

Invalid token validation

Not every server error belongs to a normal text field.

Suppose the user visits:

/verify-email?token=abc

The server must validate:

Token exists
Token has the correct format
Token hash exists in the database
Token has not expired
Token has not already been used
User still exists

Example:

import { z } from "zod";

const verifyEmailSchema = z.object({
  token: z
    .string()
    .min(
      32,
      "Verification token is invalid.",
    ),
});

app.post(
  "/api/auth/verify-email",
  async (request, response) => {
    const result =
      verifyEmailSchema.safeParse(
        request.body,
      );

    if (!result.success) {
      throw new ApiError(
        400,
        "The verification link is invalid.",
        {
          code:
            "INVALID_VERIFICATION_TOKEN",
        },
      );
    }

    const verification =
      await findVerificationByToken(
        result.data.token,
      );

    if (!verification) {
      throw new ApiError(
        400,
        "The verification link is invalid.",
        {
          code:
            "INVALID_VERIFICATION_TOKEN",
        },
      );
    }

    if (
      verification.expiresAt <=
      new Date()
    ) {
      throw new ApiError(
        410,
        "The verification link has expired.",
        {
          code:
            "VERIFICATION_TOKEN_EXPIRED",
        },
      );
    }

    if (verification.usedAt) {
      throw new ApiError(
        409,
        "This verification link has already been used.",
        {
          code:
            "VERIFICATION_TOKEN_USED",
        },
      );
    }

    await verifyUserEmail(
      verification,
    );

    response.json({
      success: true,
      message:
        "Email verified successfully.",
    });
  },
);

A token error usually becomes a page-level message rather than an input error.

Expired session validation

A protected route might reject an expired access token:

{
  "success": false,
  "code": "SESSION_EXPIRED",
  "message": "Your session has expired. Please sign in again."
}

The frontend should not inject that into:

errors.email

because the email field is not the problem.

It may instead:

Show a root error
Attempt token refresh
Redirect to login
Preserve unsaved form data
Display a session-expired dialog

Validation belongs at multiple layers

A production application may validate the same logical field several times.

HTML input
→ Basic browser semantics

React Hook Form + Zod
→ Immediate frontend feedback

Express + Zod
→ Trusted request validation

Service layer
→ Business rules

Database
→ Data constraints

This is not pointless duplication.

Each layer protects a different boundary.

Security considerations

Never trust hidden fields

A frontend may submit:

<input
  type="hidden"
  name="role"
  value="user"
/>

The user can change it to:

admin

The backend should decide privileged values itself.

Bad:

const user = await createUser({
  ...request.body,
});

Better:

const user = await createUser({
  username:
    request.body.username,
  email:
    request.body.email,
  role: "user",
});

Never return password hashes

Bad:

{
  "user": {
    "email": "user@example.com",
    "hashedPassword": "$2b$..."
  }
}

Password hashes are sensitive internal data.

Do not reveal internal errors

Bad:

{
  "message": "Prisma P2002 in src/repositories/user.repository.ts line 41"
}

Better:

{
  "success": false,
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "An account with this email already exists."
}

Log detailed technical information on the server, not in the public response.

Rate-limit sensitive routes

Registration, login, verification resend, password reset, and similar routes can be abused.

Validation does not replace rate limiting.

Valid-looking request
        ≠
Legitimate request

Advantages of server-side validation

Cannot be bypassed by disabling frontend JavaScript
Protects the database
Enforces business rules
Supports every type of client
Provides a trusted validation boundary
Protects authorization decisions
Produces consistent API contracts

Disadvantages and costs

Adds server code
Some rules appear on both frontend and backend
Database checks add latency
Error formats must be designed carefully
Shared schemas need version coordination
Async business validation is more complex
Race conditions still require database constraints

Common beginner mistakes

Trusting `request.body`

Bad:

const input =
  request.body as RegisterInput;

This is a TypeScript assertion, not runtime validation.

Better:

const result =
  registerSchema.safeParse(
    request.body,
  );

Returning only `"Invalid request"`

This is technically safe but provides a poor user experience.

Better:

{
  "code": "VALIDATION_ERROR",
  "message": "Please correct the invalid fields.",
  "fieldErrors": {
    "email": "Enter a valid email address."
  }
}

Do not reveal sensitive internal information, but provide enough information for the user to correct ordinary input mistakes.

Checking uniqueness only in application code

A pre-query can race with another request.

Use database constraints as the final guarantee.

Mixing every concern into the route

Avoid:

router.post(
  "/register",
  async (request, response) => {
    // Validation
    // Database query
    // Password hashing
    // Email sending
    // Logging
    // Response mapping
    // Error conversion
  },
);

Prefer layers:

Route
→ Middleware
→ Service
→ Repository

Interview questions

Why is frontend validation not sufficient?

Frontend code runs in an untrusted environment and can be modified or bypassed. The server must validate every request before using its data.

What validation belongs in Zod?

Zod is well suited for runtime structure, types, formats, transformations, and cross-field rules.

Database uniqueness, authorization, and token validity require trusted application or database logic.

Why should error responses contain codes?

Machine-readable codes provide stable logic even when human-readable messages change or are translated.

Why is a database unique constraint necessary if the service already checks for duplicate emails?

Concurrent requests can both pass the service check before either inserts. The database constraint provides the final integrity guarantee.

Why this evolved

Server validation protected the application, but its errors still needed to reach the correct location in the frontend. Developers needed a consistent way to transform HTTP errors into field errors, root errors, redirects, and retry states. React Hook Form’s setError() API provides that bridge.

Stage 14: Showing Backend Errors with `setError()`

Consider the complete registration flow.

The frontend validates:

Email format is correct

The backend discovers:

Email already exists

The backend responds:

{
  "success": false,
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "An account with this email already exists."
}

The frontend must:

Catch the failed HTTP request.
Read the response body.
Recognize that the error belongs to email.
Insert the error into React Hook Form.
Display it under the email input.
Optionally focus the email input.

Backend error types

Backend failures can be grouped into four categories.

Backend errors
├── Field error
├── Multiple field errors
├── Root/form error
└── Authentication/navigation error

Field error

{
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "Email already exists."
}

Use:

setError("email", {
  type: "server",
  message:
    "Email already exists.",
});

Multiple field errors

{
  "code": "VALIDATION_ERROR",
  "message": "Please correct the invalid fields.",
  "fieldErrors": {
    "email": "Enter a valid email address.",
    "password": "Password is too short."
  }
}

Call setError() for each field. The React Hook Form documentation defines setError() as setting one error per call, so multiple field failures are commonly handled by iterating over the response.

Root error

{
  "code": "EMAIL_SERVICE_UNAVAILABLE",
  "message": "Your account was created, but the verification email could not be sent."
}

Use:

setError("root.server", {
  type: "server",
  message:
    "Your account was created, but the verification email could not be sent.",
});

Authentication or navigation error

{
  "code": "SESSION_EXPIRED",
  "message": "Your session has expired."
}

Possible handling:

clearSession();
router.push("/login");

Not every API error should become a field error.

Complete TypeScript error contract

Create:

src/features/auth/auth.types.ts

export const registerFieldNames = [
  "username",
  "displayName",
  "email",
  "password",
] as const;

export type RegisterFieldName =
  (typeof registerFieldNames)[number];

export interface ApiSuccessResponse<T> {
  success: true;
  message: string;
  data: T;
}

export interface ApiErrorResponse {
  success: false;
  code: string;
  message: string;
  field?: string;
  fieldErrors?: Record<
    string,
    string
  >;
}

export interface RegisteredUser {
  id: string;
  username: string;
  displayName: string;
  email: string;
}

export interface RegisterResponseData {
  user: RegisteredUser;
}

Why is `field` typed as `string`?

You may be tempted to write:

field?: RegisterFieldName;

However, the response comes from the network.

Runtime data does not become safe merely because a TypeScript interface says it is safe.

The server might return:

{
  "field": "unexpectedField"
}

The frontend should verify the value.

Create a runtime field-name guard

import {
  registerFieldNames,
} from "./auth.types";

import type {
  RegisterFieldName,
} from "./auth.types";

export function isRegisterFieldName(
  value: unknown,
): value is RegisterFieldName {
  return (
    typeof value === "string" &&
    registerFieldNames.some(
      (fieldName) =>
        fieldName === value,
    )
  );
}

Usage:

if (
  isRegisterFieldName(
    response.field,
  )
) {
  setError(
    response.field,
    {
      type: "server",
      message:
        response.message,
    },
  );
}

After the guard, TypeScript knows that response.field is one of the supported form-field names.

Creating an Axios API layer

Install Axios:

npm install axios

Create:

src/lib/api.ts

import axios from "axios";

export const api = axios.create({
  baseURL:
    import.meta.env.VITE_API_URL ??
    "http://localhost:3000/api",

  timeout: 10_000,

  headers: {
    "Content-Type":
      "application/json",
  },

  withCredentials: true,
});

A configured instance provides one place for:

Base URL
Timeouts
Cookies
Common headers
Interceptors
Authentication refresh logic

Axios rejects unsuccessful HTTP responses by default, and its error object can distinguish a server response, a request with no response, and request-setup failures. Its isAxiosError() helper provides safe access to Axios-specific properties such as response, config, and code.

Create the registration API function

Create:

src/features/auth/auth-api.ts

import type {
  ApiSuccessResponse,
  RegisterResponseData,
} from "./auth.types";

import type {
  RegisterOutput,
} from "./register.schema";

import {
  api,
} from "../../lib/api";

export async function registerUser(
  input: RegisterOutput,
): Promise<
  ApiSuccessResponse<
    RegisterResponseData
  >
> {
  const response =
    await api.post<
      ApiSuccessResponse<
        RegisterResponseData
      >
    >(
      "/auth/register",
      input,
    );

  return response.data;
}

The API function does not contain form-specific behavior.

It does not call:

setError()

That belongs to the form layer.

API layer
→ Sends and receives HTTP data

Form layer
→ Decides how errors affect the UI

Complete React Hook Form integration

Create:

src/features/auth/RegisterForm.tsx

import axios from "axios";

import {
  zodResolver,
} from "@hookform/resolvers/zod";

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

import {
  registerSchema,
} from "./register.schema";

import type {
  RegisterInput,
  RegisterOutput,
} from "./register.schema";

import {
  registerUser,
} from "./auth-api";

import type {
  ApiErrorResponse,
} from "./auth.types";

import {
  isRegisterFieldName,
} from "./field-name.utils";

const defaultValues:
  RegisterInput = {
    username: "",
    displayName: "",
    email: "",
    password: "",
    acceptTerms: false,
  };

export default function RegisterForm() {
  const {
    register,
    handleSubmit,
    setError,
    clearErrors,
    reset,
    formState: {
      errors,
      isDirty,
      isSubmitting,
      isSubmitSuccessful,
    },
  } =
    useForm<
      RegisterInput,
      unknown,
      RegisterOutput
    >({
      defaultValues,
      resolver:
        zodResolver(
          registerSchema,
        ),
      mode: "onBlur",
    });

  async function onSubmit(
    values: RegisterOutput,
  ) {
    clearErrors("root.server");

    try {
      const response =
        await registerUser(
          values,
        );

      console.log(
        response.data.user,
      );

      reset();

      /*
       * In a real application:
       * router.push("/verify-email-sent");
       */
    } catch (error: unknown) {
      if (
        !axios.isAxiosError<
          ApiErrorResponse
        >(error)
      ) {
        setError(
          "root.server",
          {
            type: "unknown",
            message:
              "An unexpected error occurred.",
          },
        );

        return;
      }

      /*
       * Axios error with no response:
       * network failure, CORS failure,
       * timeout, or server unavailable.
       */
      if (!error.response) {
        const message =
          error.code ===
            "ECONNABORTED" ||
          error.code ===
            "ETIMEDOUT"
            ? "The request timed out. Please try again."
            : "Unable to reach the server. Check your connection and try again.";

        setError(
          "root.server",
          {
            type: "network",
            message,
          },
        );

        return;
      }

      const apiError =
        error.response.data;

      /*
       * Handle multiple backend field errors.
       */
      if (
        apiError.fieldErrors
      ) {
        let firstInvalidField:
          | string
          | undefined;

        for (const [
          fieldName,
          message,
        ] of Object.entries(
          apiError.fieldErrors,
        )) {
          if (
            !isRegisterFieldName(
              fieldName,
            )
          ) {
            continue;
          }

          firstInvalidField ??=
            fieldName;

          setError(
            fieldName,
            {
              type: "server",
              message,
            },
          );
        }

        if (
          firstInvalidField &&
          isRegisterFieldName(
            firstInvalidField,
          )
        ) {
          setError(
            firstInvalidField,
            {
              type: "server",
              message:
                apiError.fieldErrors[
                  firstInvalidField
                ],
            },
            {
              shouldFocus: true,
            },
          );
        }

        return;
      }

      /*
       * Handle one backend field error.
       */
      if (
        isRegisterFieldName(
          apiError.field,
        )
      ) {
        setError(
          apiError.field,
          {
            type: "server",
            message:
              apiError.message,
          },
          {
            shouldFocus: true,
          },
        );

        return;
      }

      /*
       * Handle non-field API errors.
       */
      setError(
        "root.server",
        {
          type:
            apiError.code,
          message:
            apiError.message,
        },
      );
    }
  }

  return (
    <form
      className="form"
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <h1>Create an account</h1>

      <div className="field">
        <label htmlFor="username">
          Username
        </label>

        <input
          id="username"
          type="text"
          autoComplete="username"
          aria-invalid={Boolean(
            errors.username,
          )}
          aria-describedby={
            errors.username
              ? "username-error"
              : "username-hint"
          }
          {...register(
            "username",
            {
              onChange: () => {
                clearErrors(
                  "username",
                );
              },
            },
          )}
        />

        <p
          id="username-hint"
          className="hint"
        >
          Use 3–20 letters,
          numbers, or underscores.
        </p>

        {errors.username && (
          <p
            id="username-error"
            className="error"
          >
            {
              errors.username
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="displayName">
          Display name
        </label>

        <input
          id="displayName"
          type="text"
          autoComplete="name"
          aria-invalid={Boolean(
            errors.displayName,
          )}
          aria-describedby={
            errors.displayName
              ? "displayName-error"
              : undefined
          }
          {...register(
            "displayName",
          )}
        />

        {errors.displayName && (
          <p
            id="displayName-error"
            className="error"
          >
            {
              errors.displayName
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="email">
          Email
        </label>

        <input
          id="email"
          type="email"
          autoComplete="email"
          aria-invalid={Boolean(
            errors.email,
          )}
          aria-describedby={
            errors.email
              ? "email-error"
              : undefined
          }
          {...register(
            "email",
            {
              onChange: () => {
                clearErrors([
                  "email",
                  "root.server",
                ]);
              },
            },
          )}
        />

        {errors.email && (
          <p
            id="email-error"
            className="error"
          >
            {errors.email.message}
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="password">
          Password
        </label>

        <input
          id="password"
          type="password"
          autoComplete="new-password"
          aria-invalid={Boolean(
            errors.password,
          )}
          aria-describedby={
            errors.password
              ? "password-error"
              : "password-hint"
          }
          {...register(
            "password",
          )}
        />

        <p
          id="password-hint"
          className="hint"
        >
          Use at least eight
          characters.
        </p>

        {errors.password && (
          <p
            id="password-error"
            className="error"
          >
            {
              errors.password
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label className="checkbox">
          <input
            type="checkbox"
            aria-invalid={Boolean(
              errors.acceptTerms,
            )}
            aria-describedby={
              errors.acceptTerms
                ? "acceptTerms-error"
                : undefined
            }
            {...register(
              "acceptTerms",
            )}
          />

          <span>
            I accept the terms.
          </span>
        </label>

        {errors.acceptTerms && (
          <p
            id="acceptTerms-error"
            className="error"
          >
            {
              errors.acceptTerms
                .message
            }
          </p>
        )}
      </div>

      {errors.root?.server && (
        <div
          className="alert"
          role="alert"
        >
          {
            errors.root.server
              .message
          }
        </div>
      )}

      {isSubmitSuccessful && (
        <p
          className="success"
          role="status"
        >
          Registration completed.
        </p>
      )}

      <button
        type="submit"
        disabled={isSubmitting}
      >
        {isSubmitting
          ? "Creating account..."
          : "Create account"}
      </button>

      {isDirty && (
        <p className="hint">
          You have unsaved changes.
        </p>
      )}
    </form>
  );
}

Step-by-step flow for a duplicate email

Suppose the user enters:

existing@example.com

Step 1: React Hook Form collects the values

{
  username: "karthik_2005",
  displayName: "Karthik",
  email: "existing@example.com",
  password: "Password123",
  acceptTerms: true
}

Step 2: Zod validates the frontend data

The email has a valid format, so frontend validation passes.

existing@example.com
        ↓
Valid email structure

Frontend validation cannot know whether it already exists in the database.

Step 3: `registerUser()` sends the request

await api.post(
  "/auth/register",
  values,
);

Step 4: Express validates the request again

registerSchema.safeParse(
  request.body,
);

The structure is valid.

Step 5: The service queries the database

const existingUser =
  await findUserByEmail(
    input.email,
  );

The user exists.

Step 6: The backend throws an API error

throw new ApiError(
  409,
  "An account with this email already exists.",
  {
    code:
      "EMAIL_ALREADY_EXISTS",
    field: "email",
  },
);

Step 7: Error middleware sends JSON

{
  "success": false,
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "An account with this email already exists."
}

Step 8: Axios rejects the promise

The request returned 409 Conflict.

Execution moves into:

catch (error) {
  // ...
}

Step 9: `isAxiosError()` narrows the error

if (
  axios.isAxiosError<
    ApiErrorResponse
  >(error)
) {
  // Axios-specific properties
  // are safely available.
}

Now we can access:

error.response?.data

Step 10: The frontend reads the field name

const apiError =
  error.response.data;

apiError.field;
// "email"

Step 11: The runtime guard verifies the field

isRegisterFieldName(
  apiError.field,
);

Result:

true

Step 12: `setError()` inserts the error

setError(
  "email",
  {
    type: "server",
    message:
      "An account with this email already exists.",
  },
  {
    shouldFocus: true,
  },
);

React Hook Form supports assigning custom errors to registered fields and optionally focusing the related input.

Step 13: React Hook Form updates its error state

Conceptually, the error object becomes:

{
  email: {
    type: "server",
    message:
      "An account with this email already exists."
  }
}

This is exposed through:

formState.errors

Therefore:

errors.email

contains the email error.

Step 14: Only the email UI reads `errors.email`

The email input contains:

aria-invalid={Boolean(
  errors.email,
)}

The email error paragraph contains:

{errors.email && (
  <p id="email-error">
    {errors.email.message}
  </p>
)}

The username input reads:

errors.username

The password input reads:

errors.password

They do not read:

errors.email

Therefore, the email message appears only beside the email field.

Backend-error lifecycle diagram

User submits registration
            ↓
Frontend Zod validation
            ↓
Axios POST request
            ↓
Express validation
            ↓
Database uniqueness check
            ↓
Email already exists
            ↓
409 response:
field = "email"
            ↓
Axios throws error
            ↓
catch(error)
            ↓
error.response.data
            ↓
setError("email", ...)
            ↓
React Hook Form error store
            ↓
errors.email
            ↓
Email component renders message

How does React Hook Form know which field is email?

It does not inspect the visual label.

It does not search for the word “email” in the page.

It does not guess based on type="email".

The connection was established when the field was registered:

register("email")

Conceptually:

Field path: "email"
        ↓
Registered input reference
        ↓
Value, validation, errors,
dirty state, touched state

Then:

setError("email", ...)

uses the same field path.

register("email")
        ↕
setError("email")
        ↕
errors.email

The string "email" is the shared key.

Nested backend errors

Suppose the form contains:

{
  address: {
    city: "",
  },
}

The input is registered as:

register("address.city")

The backend may return:

{
  "field": "address.city",
  "message": "This city is not supported."
}

The frontend can call:

setError(
  "address.city",
  {
    type: "server",
    message:
      "This city is not supported.",
  },
);

The error becomes available through:

errors.address?.city

Field paths provide the association for nested data.

Mapping multiple backend errors

Create a reusable helper:

import type {
  FieldPath,
  FieldValues,
  UseFormSetError,
} from "react-hook-form";

interface BackendFieldErrors {
  [fieldName: string]:
    | string
    | undefined;
}

interface MapErrorsOptions<
  TValues extends FieldValues,
> {
  fieldErrors:
    BackendFieldErrors;

  allowedFields:
    readonly FieldPath<
      TValues
    >[];

  setError:
    UseFormSetError<
      TValues
    >;
}

export function mapBackendFieldErrors<
  TValues extends FieldValues,
>({
  fieldErrors,
  allowedFields,
  setError,
}: MapErrorsOptions<TValues>) {
  const allowedFieldSet =
    new Set<string>(
      allowedFields,
    );

  let firstField:
    | FieldPath<TValues>
    | undefined;

  for (const [
    fieldName,
    message,
  ] of Object.entries(
    fieldErrors,
  )) {
    if (
      !message ||
      !allowedFieldSet.has(
        fieldName,
      )
    ) {
      continue;
    }

    const typedField =
      fieldName as FieldPath<
        TValues
      >;

    firstField ??=
      typedField;

    setError(
      typedField,
      {
        type: "server",
        message,
      },
      {
        shouldFocus:
          firstField ===
          typedField,
      },
    );
  }
}

Usage:

mapBackendFieldErrors({
  fieldErrors:
    apiError.fieldErrors,

  allowedFields: [
    "username",
    "displayName",
    "email",
    "password",
    "acceptTerms",
  ] as const,

  setError,
});

Should server errors disappear while typing?

Suppose the server says:

Email already exists.

Then the user changes the email.

The old server error may no longer be relevant.

You may clear it:

{...register("email", {
  onChange: () => {
    if (
      errors.email?.type ===
      "server"
    ) {
      clearErrors("email");
    }
  },
})}

This approach clears only backend errors.

It does not blindly clear client-validation errors.

A more advanced strategy is:

Server error exists
        ↓
User edits field
        ↓
Clear stale server error
        ↓
Run schema validation again

Do not leave “Email already exists” visible after the user has entered a completely different email.

Avoid clearing all errors on every keystroke

Bad:

onChange={() => {
  clearErrors();
}}

This may remove errors from unrelated fields and create a misleading form state.

Better:

onChange={() => {
  clearErrors("email");
}}

Clear only the stale error associated with the changed value.

Field errors versus root errors

Use field errors when the user can correct a specific input.

Email already exists
→ email field

Username already taken
→ username field

Password violates policy
→ password field

Use root errors when no single input is responsible.

Server unavailable
Session expired
Too many requests
Payment service unavailable
Unexpected failure

Example:

setError(
  "root.server",
  {
    type:
      "SERVICE_UNAVAILABLE",
    message:
      "Registration is temporarily unavailable.",
  },
);

Do not trust backend field names blindly

This is risky:

setError(
  apiError.field as keyof RegisterInput,
  {
    message:
      apiError.message,
  },
);

The type assertion tells TypeScript to trust an unverified network value.

Instead:

if (
  isRegisterFieldName(
    apiError.field,
  )
) {
  setError(
    apiError.field,
    {
      type: "server",
      message:
        apiError.message,
    },
  );
}

Runtime data needs runtime validation.

Advantages of structured backend-error mapping

Errors appear beside relevant fields
Users know what to correct
The API remains frontend-independent
Error codes support localization
Multiple field errors can be displayed
Root errors remain separate
TypeScript protects known field names
Focus can move to the first invalid field

Disadvantages and complexity

Backend and frontend must agree on error shapes
Field paths must remain stable
Network responses must be validated
Different forms need different allowed-field lists
Some errors become stale after editing
Localization requires message or code design
Nested field paths require careful handling

Common beginner mistakes

Displaying every backend error as a toast

A toast such as:

Validation failed

may disappear before the user corrects the field.

Field errors should usually remain near the relevant control.

Use a toast for broader events such as:

Profile saved successfully.

Putting every error under email

Bad:

catch (error) {
  setError("email", {
    message:
      "Something went wrong.",
  });
}

A network failure is not an email error.

Comparing error messages

Bad:

if (
  message ===
  "Email already exists"
) {
  // ...
}

Use a stable code or field property.

Assuming Axios errors always contain a response

For network failures:

error.response

may be undefined.

Handle:

Server response error
Network/no-response error
Request configuration error
Unknown programming error

separately.

Interview questions

How does `setError("email")` create `errors.email`?

React Hook Form uses field names as keys or paths. Calling setError("email", ...) places an error at the email path in the form's error state, which is exposed as formState.errors.email.

Why does the error appear only under the email input?

Only the email component renders errors.email. Other fields render their own error paths, such as errors.username or errors.password.

What is the difference between a field error and a root error?

A field error belongs to a specific user-editable value. A root error represents a form-wide, network, session, or server problem.

Why should backend field names be checked at runtime?

Network responses are untrusted runtime data. A TypeScript type or assertion cannot guarantee that the server actually returned a valid form-field name.

Why this evolved

Mapping backend errors solved the data-flow problem, but displaying an error visually is not enough. Users navigate forms using keyboards, screen readers, zoom, speech input, and many other assistive technologies. Modern forms therefore need explicit semantic and accessibility architecture.

Stage 15: Accessible Production Forms

Accessibility is not an optional layer added after the form works.

The form's structure determines whether users can:

Discover fields
Understand instructions
Identify errors
Navigate with a keyboard
Complete the form with a screen reader
Recover from failed submission
Understand loading and success states

The W3C recommends properly associated labels, clear instructions, accessible validation messages, and server-side validation in addition to client-side validation.

Accessible form model

A field usually needs four relationships.

Field
├── Accessible name
├── Instructions
├── Current validity
└── Error description

Example:

<label for="password">
  Password
</label>

<input
  id="password"
  aria-describedby="
    password-hint
    password-error
  "
  aria-invalid="true"
/>

<p id="password-hint">
  Use at least eight characters.
</p>

<p id="password-error">
  Password must include a number.
</p>

1. Labels

Every input should have an accessible name.

The most reliable approach for ordinary form controls is:

<label for="email">
  Email
</label>

<input
  id="email"
  type="email"
/>

The connection is:

label for="email"
        ↓
input id="email"

W3C guidance states that labels should describe the purpose of their associated controls.

Why labels matter

A visible label helps:

Sighted users
Screen-reader users
Speech-input users
Users with memory or attention difficulties
Users reviewing previously entered data

Clicking a correctly associated label also focuses or activates the control.

Do not use placeholder as the only label

Bad:

<input
  type="email"
  placeholder="Email"
/>

Problems:

Placeholder disappears while typing
It may have low contrast
It does not consistently provide the same labeling behavior
Users may confuse examples with entered values
It becomes difficult to review the form

Better:

<label for="email">
  Email
</label>

<input
  id="email"
  type="email"
  placeholder="name@example.com"
/>

The label explains the field.

The placeholder provides an optional example.

2. `id` and `htmlFor`

In React, HTML's for attribute becomes:

htmlFor

Example:

<label htmlFor="email">
  Email
</label>

<input id="email" />

The values must match exactly.

Bad:

<label htmlFor="userEmail">
  Email
</label>

<input id="email" />

The label is not associated with the input.

3. Instructions and hints

Fields often require more than a short label.

Example:

<label htmlFor="username">
  Username
</label>

<input
  id="username"
  aria-describedby="username-hint"
/>

<p id="username-hint">
  Use 3–20 letters, numbers,
  or underscores.
</p>

aria-describedby connects the control to one or more elements that provide additional descriptive information.

Multiple descriptions

An input can reference multiple IDs separated by spaces.

<input
  id="password"
  aria-describedby={
    errors.password
      ? "password-hint password-error"
      : "password-hint"
  }
/>

The related elements:

<p id="password-hint">
  Use at least eight characters.
</p>

{errors.password && (
  <p id="password-error">
    Include at least one number.
  </p>
)}

The accessible description can include both the instruction and the error.

4. `aria-invalid`

When a value has been determined to be invalid:

<input
  aria-invalid="true"
/>

When it is valid or has not been marked invalid:

<input
  aria-invalid="false"
/>

In React:

aria-invalid={Boolean(
  errors.email,
)}

aria-invalid communicates that the application does not accept the current value. It should normally be set after validation rather than marking untouched empty fields as invalid immediately.

`aria-invalid` does not display an error

This:

aria-invalid="true"

does not automatically:

Show red text
Create a message
Prevent submission
Explain how to correct the value

It only communicates the state to assistive technology.

You still need:

<p id="email-error">
  Enter a valid email address.
</p>

5. `aria-describedby`

<input
  id="email"
  aria-describedby="email-error"
/>

<p id="email-error">
  Email already exists.
</p>

The input references the error element's id.

Input:
aria-describedby="email-error"
                ↓
Error:
id="email-error"

This relationship helps assistive technology associate the message with the field.

`aria-errormessage`

Another option is:

<input
  id="email"
  aria-invalid="true"
  aria-errormessage="email-error"
/>

<p id="email-error">
  Email already exists.
</p>

aria-errormessage explicitly identifies the element containing the error, and it should be used when the control is currently invalid.

For broad compatibility, many form implementations continue to use:

aria-describedby

for hints and errors.

Whichever approach you choose, test it with the assistive technologies important to your users.

6. Required fields

Use the native required attribute when appropriate:

<input
  id="email"
  type="email"
  required
/>

Native required adds semantic meaning and browser behavior.

When custom validation uses:

<form noValidate>

the browser's validation popup is disabled, but the required attribute can still communicate semantics.

<input
  required
  {...register("email")}
/>

Also indicate required fields visually:

<label htmlFor="email">
  Email
  <span aria-hidden="true">
    *
  </span>
  <span className="sr-only">
    required
  </span>
</label>

Do not rely only on color or a red asterisk whose meaning is never explained. Native required is preferable for semantic HTML controls; ARIA alone changes accessibility information but does not add native validation behavior.

7. Keyboard navigation

A form should be usable without a mouse.

Users should be able to:

Tab
→ Move to the next interactive control

Shift + Tab
→ Move to the previous control

Space
→ Toggle checkbox or activate selected controls

Arrow keys
→ Navigate native radio groups and select controls

Enter
→ Submit where appropriate

Use native controls whenever possible:

<button>
<input>
<select>
<textarea>

Avoid replacing them with:

<div onClick={...}>

A <div> does not automatically provide:

Keyboard behavior
Focus behavior
Button semantics
Disabled behavior
Form submission behavior

Bad custom button

<div
  onClick={submitForm}
>
  Submit
</div>

A keyboard user may not be able to focus or activate it.

Better:

<button type="submit">
  Submit
</button>

8. Button types

Inside a form:

<button>

defaults to submit behavior.

Use explicit types.

<button type="submit">
  Create account
</button>

<button type="button">
  Show password
</button>

<button type="button">
  Add work experience
</button>

React's documentation warns that a button without a type inside a form submits by default, so custom button components should make their behavior explicit.

9. Focus management

After failed submission, users need to find the problem.

React Hook Form can focus a registered field:

setError(
  "email",
  {
    type: "server",
    message:
      "Email already exists.",
  },
  {
    shouldFocus: true,
  },
);

For client validation, React Hook Form can also focus the first invalid registered field when configured to do so.

Error summary for large forms

For long forms, focusing only one field may not show the complete problem.

Display a summary:

interface ErrorSummaryProps {
  errors: Array<{
    fieldId: string;
    label: string;
    message: string;
  }>;
}

function ErrorSummary({
  errors,
}: ErrorSummaryProps) {
  if (errors.length === 0) {
    return null;
  }

  return (
    <section
      aria-labelledby="error-summary-title"
      className="error-summary"
      role="alert"
      tabIndex={-1}
    >
      <h2 id="error-summary-title">
        Correct the following
        problems
      </h2>

      <ul>
        {errors.map(
          (error) => (
            <li
              key={
                error.fieldId
              }
            >
              <a
                href={`#${error.fieldId}`}
              >
                {error.label}:{" "}
                {error.message}
              </a>
            </li>
          ),
        )}
      </ul>
    </section>
  );
}

W3C guidance recommends that an error summary clearly identify each problem, explain how to fix it, and link to the corresponding control.

Focusing the error summary

import {
  useEffect,
  useRef,
} from "react";

function ErrorSummary({
  errors,
}: ErrorSummaryProps) {
  const summaryRef =
    useRef<HTMLElement>(null);

  useEffect(() => {
    if (errors.length > 0) {
      summaryRef.current?.focus();
    }
  }, [errors]);

  if (errors.length === 0) {
    return null;
  }

  return (
    <section
      ref={summaryRef}
      role="alert"
      tabIndex={-1}
      aria-labelledby="error-summary-title"
    >
      <h2 id="error-summary-title">
        Correct the following
        problems
      </h2>

      {/* Error links */}
    </section>
  );
}

tabIndex={-1} allows programmatic focus without adding the section to normal Tab navigation.

Do not move focus after every keystroke.

Focus changes should be deliberate and predictable.

10. Live regions

Some messages appear dynamically:

Checking username...
Username is available.
Saving...
Profile saved.

Use an appropriate live region:

<p
  role="status"
  aria-live="polite"
>
  {statusMessage}
</p>

For an urgent failure:

<div role="alert">
  Your session expired.
</div>

Use live regions sparingly.

If every change is announced, the interface becomes noisy and difficult to use.

`role="status"` versus `role="alert"`

Use status for non-urgent updates:

Uploading file...
Draft saved.
Registration complete.

Use alert for important errors requiring attention:

Payment failed.
Session expired.
Unable to save changes.

Do not apply role="alert" to every character-count update.

11. Loading state

An accessible loading state should communicate more than a spinner.

<button
  type="submit"
  disabled={isSubmitting}
>
  {isSubmitting
    ? "Creating account..."
    : "Create account"}
</button>

This provides visible text and prevents duplicate interaction.

You may also include:

<p
  role="status"
  aria-live="polite"
>
  {isSubmitting
    ? "Creating your account."
    : ""}
</p>

Disabled versus `aria-disabled`

Native:

<button disabled>
  Submit
</button>

prevents interaction and usually removes the control from the normal focus sequence.

<button aria-disabled="true">
  Submit
</button>

communicates the disabled state but does not automatically prevent clicking.

ARIA describes semantics; developers must still implement behavior.

For a normal submit button, prefer native:

disabled={isSubmitting}

12. Do not disable submit solely because the form is invalid

Some forms use:

<button
  disabled={!isValid}
>
  Submit
</button>

This can create accessibility and usability problems:

Users may not understand why the button is disabled.
They cannot submit to reveal missing-field errors.
The disabled button cannot explain what remains incomplete.
Validation may not have run yet.

A common approach is:

<button
  disabled={isSubmitting}
>
  Submit
</button>

Allow submission, then clearly display and focus validation errors.

There are valid exceptions, but a disabled button should never be the only explanation of invalid form state.

13. Field groups

Related checkboxes or radio buttons should be grouped.

<fieldset>
  <legend>
    Preferred contact method
  </legend>

  <label>
    <input
      type="radio"
      value="email"
      {...register(
        "contactMethod",
      )}
    />
    Email
  </label>

  <label>
    <input
      type="radio"
      value="phone"
      {...register(
        "contactMethod",
      )}
    />
    Phone
  </label>
</fieldset>

fieldset and legend provide a semantic group label.

This is clearer than showing several unrelated labels without context.

14. Error text should be useful

Bad:

Invalid input.

Better:

Enter an email address in the format name@example.com.

Bad:

Password error.

Better:

Password must contain at least eight characters.

An error should answer:

What is wrong?
How can I correct it?

15. Do not rely only on color

Bad:

Red border = invalid
Green border = valid

Some users cannot reliably distinguish those colors.

Use:

Error text
Icons with text
aria-invalid
Clear labels
Visible focus styles

Color can support the message, but should not be the only signal.

Complete accessible reusable input

import {
  forwardRef,
} from "react";

import type {
  InputHTMLAttributes,
  ReactNode,
} from "react";

interface AccessibleInputProps
  extends InputHTMLAttributes<HTMLInputElement> {
  id: string;
  label: string;
  error?: string;
  hint?: ReactNode;
  requiredLabel?: boolean;
}

const AccessibleInput =
  forwardRef<
    HTMLInputElement,
    AccessibleInputProps
  >(function AccessibleInput(
    {
      id,
      label,
      error,
      hint,
      requiredLabel,
      required,
      ...inputProps
    },
    ref,
  ) {
    const hintId =
      hint
        ? `${id}-hint`
        : undefined;

    const errorId =
      error
        ? `${id}-error`
        : undefined;

    const describedBy = [
      hintId,
      errorId,
    ]
      .filter(Boolean)
      .join(" ") || undefined;

    return (
      <div className="field">
        <label htmlFor={id}>
          {label}

          {requiredLabel && (
            <>
              <span
                aria-hidden="true"
              >
                {" *"}
              </span>

              <span className="sr-only">
                {" required"}
              </span>
            </>
          )}
        </label>

        <input
          {...inputProps}
          id={id}
          ref={ref}
          required={required}
          aria-invalid={Boolean(
            error,
          )}
          aria-describedby={
            describedBy
          }
        />

        {hint && (
          <p
            id={hintId}
            className="hint"
          >
            {hint}
          </p>
        )}

        {error && (
          <p
            id={errorId}
            className="error"
          >
            {error}
          </p>
        )}
      </div>
    );
  });

export default AccessibleInput;

Screen-reader-only CSS

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  white-space: nowrap;
  border: 0;
  clip: rect(0, 0, 0, 0);
  clip-path: inset(50%);
}

Use visually hidden content for information that assistive technology needs, not as a substitute for visible instructions that all users would benefit from.

Complete accessible React Hook Form example

import {
  useMemo,
} from "react";

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

interface ContactFormValues {
  name: string;
  email: string;
  subject: string;
  message: string;
  contactMethod: "email" | "phone";
  phone: string;
}

const defaultValues:
  ContactFormValues = {
    name: "",
    email: "",
    subject: "",
    message: "",
    contactMethod: "email",
    phone: "",
  };

export default function ContactForm() {
  const {
    register,
    handleSubmit,
    watch,
    formState: {
      errors,
      isSubmitting,
    },
  } =
    useForm<ContactFormValues>({
      defaultValues,
      mode: "onSubmit",
    });

  const contactMethod =
    watch("contactMethod");

  const errorSummary =
    useMemo(() => {
      const items: Array<{
        fieldId: string;
        label: string;
        message: string;
      }> = [];

      if (errors.name?.message) {
        items.push({
          fieldId: "name",
          label: "Name",
          message:
            errors.name.message,
        });
      }

      if (errors.email?.message) {
        items.push({
          fieldId: "email",
          label: "Email",
          message:
            errors.email.message,
        });
      }

      if (
        errors.subject?.message
      ) {
        items.push({
          fieldId: "subject",
          label: "Subject",
          message:
            errors.subject.message,
        });
      }

      if (
        errors.message?.message
      ) {
        items.push({
          fieldId: "message",
          label: "Message",
          message:
            errors.message.message,
        });
      }

      if (errors.phone?.message) {
        items.push({
          fieldId: "phone",
          label: "Phone",
          message:
            errors.phone.message,
        });
      }

      return items;
    }, [errors]);

  async function onSubmit(
    values: ContactFormValues,
  ) {
    await new Promise(
      (resolve) => {
        setTimeout(
          resolve,
          1000,
        );
      },
    );

    console.log(values);
  }

  return (
    <form
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <h1>Contact support</h1>

      <p>
        Fields marked with an
        asterisk are required.
      </p>

      <ErrorSummary
        errors={errorSummary}
      />

      <AccessibleInput
        id="name"
        label="Name"
        required
        requiredLabel
        autoComplete="name"
        error={
          errors.name?.message
        }
        {...register("name", {
          required:
            "Enter your name.",
        })}
      />

      <AccessibleInput
        id="email"
        label="Email"
        type="email"
        required
        requiredLabel
        autoComplete="email"
        hint="For example, name@example.com."
        error={
          errors.email?.message
        }
        {...register("email", {
          required:
            "Enter your email address.",

          pattern: {
            value:
              /^[^\s@]+@[^\s@]+\.[^\s@]+$/,
            message:
              "Enter an email address in the format name@example.com.",
          },
        })}
      />

      <AccessibleInput
        id="subject"
        label="Subject"
        required
        requiredLabel
        error={
          errors.subject?.message
        }
        {...register(
          "subject",
          {
            required:
              "Enter a subject.",
          },
        )}
      />

      <div className="field">
        <label htmlFor="message">
          Message
          <span aria-hidden="true">
            {" *"}
          </span>
          <span className="sr-only">
            {" required"}
          </span>
        </label>

        <textarea
          id="message"
          rows={6}
          required
          aria-invalid={Boolean(
            errors.message,
          )}
          aria-describedby={
            errors.message
              ? "message-hint message-error"
              : "message-hint"
          }
          {...register(
            "message",
            {
              required:
                "Enter a message.",

              minLength: {
                value: 20,
                message:
                  "Your message must contain at least 20 characters.",
              },
            },
          )}
        />

        <p
          id="message-hint"
          className="hint"
        >
          Include enough information
          for us to understand the
          problem.
        </p>

        {errors.message && (
          <p
            id="message-error"
            className="error"
          >
            {
              errors.message
                .message
            }
          </p>
        )}
      </div>

      <fieldset>
        <legend>
          Preferred contact method
        </legend>

        <label>
          <input
            type="radio"
            value="email"
            {...register(
              "contactMethod",
            )}
          />
          Email
        </label>

        <label>
          <input
            type="radio"
            value="phone"
            {...register(
              "contactMethod",
            )}
          />
          Phone
        </label>
      </fieldset>

      {contactMethod ===
        "phone" && (
        <AccessibleInput
          id="phone"
          label="Phone number"
          type="tel"
          required
          requiredLabel
          autoComplete="tel"
          error={
            errors.phone?.message
          }
          {...register(
            "phone",
            {
              required:
                "Enter your phone number.",

              pattern: {
                value:
                  /^[0-9+\-\s]{8,15}$/,
                message:
                  "Enter a valid phone number.",
              },
            },
          )}
        />
      )}

      <button
        type="submit"
        disabled={isSubmitting}
      >
        {isSubmitting
          ? "Sending message..."
          : "Send message"}
      </button>

      <p
        role="status"
        aria-live="polite"
      >
        {isSubmitting
          ? "Your message is being sent."
          : ""}
      </p>
    </form>
  );
}

Accessibility testing checklist

Test using:

Keyboard only
├── Can every field be reached?
├── Is focus visible?
├── Is the order logical?
└── Can every action be performed?

Screen reader
├── Is each field named?
├── Are hints associated?
├── Are errors announced?
└── Are status changes understandable?

Zoom and reflow
├── Does the form work at high zoom?
├── Is horizontal scrolling avoided?
└── Does text remain readable?

Error recovery
├── Is the first problem easy to find?
├── Does each error explain the fix?
└── Are entered values preserved?

Automated tools can find some problems.

They cannot fully judge:

Whether instructions make sense
Whether focus movement is confusing
Whether error text is helpful
Whether the complete task is usable

Manual testing remains necessary.

Advantages of accessible form architecture

Supports more users
Improves keyboard navigation
Improves error recovery
Creates clearer labels and instructions
Usually improves mobile usability
Produces more maintainable semantics
Reduces ambiguity for every user
Helps forms work across different technologies

Disadvantages and costs

Requires deliberate design
Custom components need more work
Dynamic announcements require testing
Screen-reader behavior can vary
Complex widgets require strong keyboard support
Accessibility cannot be verified by one automated test

These are not reasons to omit accessibility.

They are reasons to include it in the original architecture instead of adding it after development.

Common beginner mistakes

Adding ARIA instead of semantic HTML

Bad:

<div
  role="button"
  tabIndex={0}
>
  Submit
</div>

Better:

<button type="submit">
  Submit
</button>

Use native semantics first.

Applying `aria-invalid` to every empty field immediately

The user may not have had a chance to fill it.

Show validation at a deliberate time:

After submit
On blur
After the field has been touched
During correction after a failed submit

Moving focus on every validation change

This makes typing difficult and disorienting.

Focus the first invalid control after submission or another clear workflow transition.

Removing focus outlines

Bad:

*:focus {
  outline: none;
}

Users navigating with a keyboard need a visible focus indicator.

Interview questions

What does `aria-invalid` do?

It communicates that the current value does not meet the application's accepted format or rule. It does not display an error or prevent submission by itself.

What does `aria-describedby` do?

It associates a control with one or more elements that provide additional descriptive text, such as instructions or an error message.

Why are labels important?

Labels provide accessible names, make form purposes clear, and allow clicking the label to focus or activate the associated native control.

Why use `fieldset` and `legend`?

They semantically group related fields such as radio buttons or checkboxes and provide a group-level label.

Should a form rely only on red borders for errors?

No. Error state should also be communicated through text and semantic attributes because color alone is not sufficient.

Why this evolved

Accessible forms made interaction understandable across different input and assistive technologies. As forms became larger and more dynamic, teams also needed to ensure that validation and state updates did not make typing slow. This led to deeper attention to render performance and subscription-based form architecture.

Stage 16: Form Performance

Form performance discussions often become oversimplified.

You may hear:

Formik is slow.
React Hook Form is fast.
Uncontrolled inputs never rerender.
Controlled inputs are bad.

These statements are too absolute.

Actual performance depends on:

Number of fields
Validation mode
Component structure
Watched values
Schema cost
Controlled components
Parent rerenders
Dynamic arrays
Expensive child components
Browser and device
Network requests
User-visible latency

What is a React render?

When state changes, React may run a component function again.

function RegistrationForm() {
  console.log(
    "RegistrationForm render",
  );

  return (
    <form>
      {/* JSX */}
    </form>
  );
}

Running the component again is a React render.

It does not necessarily mean the browser recreates every DOM node.

The simplified flow is:

State update
    ↓
Component function runs
    ↓
New React element description
    ↓
React compares previous and next output
    ↓
Required DOM changes are committed

Controlled input render flow

const [email, setEmail] =
  useState("");

<input
  value={email}
  onChange={(event) => {
    setEmail(
      event.target.value,
    );
  }}
/>

Each keystroke updates state.

User types "k"
       ↓
onChange runs
       ↓
setEmail("k")
       ↓
Form component renders
       ↓
Input receives value "k"

React's official documentation states that controlled inputs update state on every keystroke, and a large surrounding tree can become slow if it rerenders for each edit. It recommends isolating the input state in a smaller component where possible.

Controlled input does not automatically mean slow

This is usually fine:

function SearchBox() {
  const [
    query,
    setQuery,
  ] = useState("");

  return (
    <input
      value={query}
      onChange={(event) => {
        setQuery(
          event.target.value,
        );
      }}
    />
  );
}

A small component rerender is generally inexpensive.

Problems appear when the state is located too high:

function EntireDashboard() {
  const [
    search,
    setSearch,
  ] = useState("");

  return (
    <>
      <Navigation />
      <LargeAnalyticsChart />
      <HugeDataTable />
      <ExpensiveRecommendations />

      <input
        value={search}
        onChange={(event) => {
          setSearch(
            event.target.value,
          );
        }}
      />
    </>
  );
}

Now every keystroke causes EntireDashboard() to run again.

Better component boundary

function EntireDashboard() {
  return (
    <>
      <Navigation />
      <LargeAnalyticsChart />
      <HugeDataTable />
      <ExpensiveRecommendations />
      <SearchForm />
    </>
  );
}

function SearchForm() {
  const [
    search,
    setSearch,
  ] = useState("");

  return (
    <input
      value={search}
      onChange={(event) => {
        setSearch(
          event.target.value,
        );
      }}
    />
  );
}

Only the relevant form subtree owns the rapidly changing state.

Component boundaries are often a more important optimization than replacing the complete form library.

Controlled form diagram

Email keystroke
      ↓
setValues()
      ↓
Form component renders
      ↓
Username JSX recalculated
Email JSX recalculated
Password JSX recalculated
Buttons recalculated
Debug panel recalculated
      ↓
React commits required DOM update

“JSX recalculated” does not mean that every DOM node changed.

But the component function and its non-memoized child calls may still perform work.

Formik-style central state

A form library using central React state may broadly follow:

Field changes
      ↓
Central form state changes
      ↓
Form context/provider updates
      ↓
Subscribed or consuming
components render

Performance depends on:

Which state each field consumes
Whether optimized field components are used
Context boundaries
Memoization
Validation cost

Formik can be entirely suitable for many applications.

Architecture should be evaluated using the real form, not stereotypes.

React Hook Form registration flow

<input
  {...register("email")}
/>

React Hook Form registers the input for value tracking, validation, and submission.

Conceptually:

User types
      ↓
Native input value changes
      ↓
Registered event handler runs
      ↓
Internal field state updates
      ↓
Subscribed form state may update
      ↓
Relevant consumers rerender

The parent does not necessarily need a React-state update solely to place the latest character into the native input.

React Hook Form `formState` subscriptions

Suppose a component reads:

const {
  formState: {
    errors,
  },
} = useForm();

It consumes errors.

If it reads:

const {
  formState: {
    errors,
    isDirty,
    isValid,
    isSubmitting,
  },
} = useForm();

it consumes more form-state properties.

React Hook Form documents that formState is wrapped in a Proxy so it can avoid work for state properties that have not been subscribed to.

Important destructuring pattern

Prefer reading needed state during render:

const {
  formState: {
    isDirty,
    errors,
  },
} = useForm();

Avoid treating the complete object as an ordinary mutable object and expecting arbitrary later reads to establish optimal subscriptions.

Think explicitly about which state the component needs.

React Hook Form does rerender

React Hook Form may rerender when:

A validation error changes
isDirty changes
isValid changes
isSubmitting changes
touchedFields changes
watch() observes a changed value
Controller updates a controlled field
A field array changes
The parent component rerenders

The realistic claim is:

React Hook Form can avoid requiring a parent React-state update for every native input keystroke and can limit updates through subscriptions.

Not:

React Hook Form never rerenders.

Render comparison: three fields

Suppose a user types ten characters into the email field.

Simple controlled parent

Approximate component executions:

Initial render: 1
Ten state updates: 10
Total: about 11 form renders

Registered uncontrolled input

Possible flow:

Initial render: 1
First dirty-state change: render
Validation error changes: render when applicable
Submission-state changes: later renders

The exact number depends on:

Validation mode
State consumed
Watched values
React development mode
Component structure
Library version

Do not publish benchmark numbers without measuring the actual implementation.

Development mode can confuse render counting

React development features may intentionally run components or setup logic more than once to identify unsafe behavior.

Do not conclude that production performance is broken solely because:

console.log("render");

appears multiple times in development.

Measure production builds and user-visible interaction.

Performance problem 1: Watching the entire form

const values = watch();

Now the component depends on every registered value.

Any field changes
      ↓
watch() value changes
      ↓
Component rerenders

This may be reasonable for:

Live JSON preview
Small form builder
Form-debugging tools

It is unnecessary when only one conditional field depends on the country.

Better:

const country =
  watch("country");

Isolate watched values

function StateField({
  control,
}: {
  control:
    Control<AddressFormValues>;
}) {
  const country =
    useWatch({
      control,
      name: "country",
    });

  if (country !== "india") {
    return null;
  }

  return (
    <input
      {...register("state")}
    />
  );
}

In a real implementation, pass or retrieve the required registration methods appropriately.

The key idea is:

Only the conditional section
subscribes to country

instead of making the complete parent form depend on it.

Performance problem 2: Validating on every keystroke

useForm({
  mode: "onChange",
  resolver:
    zodResolver(
      largeSchema,
    ),
});

This can run validation frequently.

For a small form, that may be fine.

For a large schema containing:

Complex refinements
Large arrays
Expensive transformations
Async validation
Many cross-field checks

it can become noticeable.

Choose validation timing deliberately

`onSubmit`

useForm({
  mode: "onSubmit",
});

Advantages:

Lowest validation frequency
Less interruption while typing
Good for simple forms

Disadvantage:

Feedback arrives after submission

`onBlur`

useForm({
  mode: "onBlur",
});

Advantages:

Balanced feedback
Avoids checking every character
User finishes a field before seeing most errors

Disadvantage:

Some users may not notice errors until leaving fields

`onChange`

useForm({
  mode: "onChange",
});

Advantages:

Immediate feedback
isValid can update continuously

Disadvantages:

More validation runs
Errors may appear too early
Potential performance cost

Practical pattern

A common production strategy is:

Before first submit
→ Validate on submit or blur

After an error appears
→ Revalidate that field while editing

This gives useful correction feedback without aggressively validating untouched fields.

Performance problem 3: Expensive asynchronous validation

Bad:

register("username", {
  validate: async (username) => {
    const response =
      await api.get(
        `/users/check/${username}`,
      );

    return (
      response.data.available ||
      "Username is taken."
    );
  },
});

With mode: "onChange", this might send a request for:

k
ka
kar
kart
karth
karthi
karthik

Problems:

Too many requests
Increased server load
Out-of-order responses
Flickering validation
Rate-limit consumption
Slower typing experience

Better asynchronous validation

Use local checks first:

Empty?
Too short?
Invalid characters?
        ↓
Only then consider
availability request

Debounce the remote request and cancel stale requests.

import {
  useEffect,
  useState,
} from "react";

function useUsernameAvailability(
  username: string,
) {
  const [
    status,
    setStatus,
  ] = useState<
    | "idle"
    | "checking"
    | "available"
    | "unavailable"
    | "error"
  >("idle");

  useEffect(() => {
    const normalized =
      username.trim();

    if (
      normalized.length < 3
    ) {
      setStatus("idle");
      return;
    }

    const controller =
      new AbortController();

    const timeoutId =
      window.setTimeout(
        async () => {
          setStatus(
            "checking",
          );

          try {
            const response =
              await fetch(
                `/api/users/username-availability?username=${encodeURIComponent(
                  normalized,
                )}`,
                {
                  signal:
                    controller.signal,
                },
              );

            if (!response.ok) {
              throw new Error(
                "Request failed",
              );
            }

            const result =
              (await response.json()) as {
                available: boolean;
              };

            setStatus(
              result.available
                ? "available"
                : "unavailable",
            );
          } catch (error) {
            if (
              error instanceof
                DOMException &&
              error.name ===
                "AbortError"
            ) {
              return;
            }

            setStatus("error");
          }
        },
        400,
      );

    return () => {
      window.clearTimeout(
        timeoutId,
      );

      controller.abort();
    };
  }, [username]);

  return status;
}

The authoritative uniqueness check must still occur during backend submission.

Availability checks improve feedback.

They do not reserve the username.

Performance problem 4: Large parent components

Bad:

function ApplicationPage() {
  const form =
    useForm<ApplicationValues>();

  const allValues =
    form.watch();

  return (
    <>
      <ExpensiveHeader />
      <LargeResumePreview
        values={allValues}
      />
      <ApplicationForm
        form={form}
      />
      <RecommendationEngine
        values={allValues}
      />
    </>
  );
}

Every field may cause multiple expensive sections to update.

Solutions include:

Smaller component boundaries
Narrow subscriptions
Debounced preview updates
useDeferredValue where suitable
Memoized expensive components
Rendering previews only when required

Performance problem 5: Passing unstable props

Consider:

<ProfileInput
  options={{
    required: true,
  }}
/>

The object is recreated on every render.

For a memoized child, unstable references may defeat memoization.

This matters only when profiling shows a real issue.

Do not add useMemo() everywhere automatically.

Premature memoization can make code harder to understand without improving user experience.

Performance problem 6: Controlled third-party components

Some components require:

<Controller
  name="country"
  control={control}
  render={({ field }) => (
    <CustomSelect
      value={field.value}
      onChange={field.onChange}
    />
  )}
/>

This field is controlled.

Using Controller does not make the component uncontrolled.

React Hook Form
      ↓
Controller
      ↓
Controlled custom component

Performance still depends on the controlled component's implementation and subscription boundaries.

Use register() for native inputs where practical.

Use Controller where controlled integration is genuinely required.

Performance problem 7: Rendering complete error objects

Avoid passing the entire form state to every field:

<Input
  formState={formState}
  name="email"
/>

Now every input may depend on a large changing object.

Prefer narrow props:

<Input
  error={
    errors.email?.message
  }
/>

Or use field-level subscription APIs when the component architecture requires them.

Performance problem 8: Giant schemas

A single schema may validate:

User profile
Billing address
Shipping address
Company
Tax details
Twenty work experiences
Fifty uploaded files

Consider splitting validation by workflow or step.

const personalSchema =
  z.object({
    firstName:
      z.string().min(1),

    lastName:
      z.string().min(1),
  });

const addressSchema =
  z.object({
    country:
      z.string().min(1),

    city:
      z.string().min(1),
  });

const completeSchema =
  z.object({
    personal:
      personalSchema,

    address:
      addressSchema,
  });

A multi-step form may validate only the current section before moving forward.

Measuring rerenders

Create a helper:

import {
  useRef,
} from "react";

function RenderCounter({
  name,
}: {
  name: string;
}) {
  const renderCount =
    useRef(0);

  renderCount.current += 1;

  return (
    <small>
      {name} renders:{" "}
      {renderCount.current}
    </small>
  );
}

Use during development:

function EmailSection() {
  return (
    <div>
      <RenderCounter
        name="EmailSection"
      />

      {/* Email input */}
    </div>
  );
}

This is a debugging aid, not a production benchmark.

Use the React Profiler

For meaningful investigation:

Record the interaction.
Type in the slow field.
Identify which components rendered.
Find expensive renders.
Inspect why their props or state changed.
Optimize the actual bottleneck.
Measure again.

Do not optimize based only on assumptions.

Complete controlled-form comparison

import {
  useState,
} from "react";

interface Values {
  firstName: string;
  lastName: string;
  email: string;
}

export function ControlledForm() {
  const [
    values,
    setValues,
  ] = useState<Values>({
    firstName: "",
    lastName: "",
    email: "",
  });

  console.log(
    "Controlled form render",
  );

  function update(
    field: keyof Values,
    value: string,
  ) {
    setValues(
      (currentValues) => ({
        ...currentValues,
        [field]: value,
      }),
    );
  }

  return (
    <form>
      <input
        value={
          values.firstName
        }
        onChange={(event) => {
          update(
            "firstName",
            event.target.value,
          );
        }}
      />

      <input
        value={
          values.lastName
        }
        onChange={(event) => {
          update(
            "lastName",
            event.target.value,
          );
        }}
      />

      <input
        value={values.email}
        onChange={(event) => {
          update(
            "email",
            event.target.value,
          );
        }}
      />
    </form>
  );
}

Every field change calls:

setValues()

which schedules a render of ControlledForm.

Complete React Hook Form comparison

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

interface Values {
  firstName: string;
  lastName: string;
  email: string;
}

export function HookForm() {
  const {
    register,
    handleSubmit,
    formState: {
      errors,
      isDirty,
    },
  } = useForm<Values>({
    defaultValues: {
      firstName: "",
      lastName: "",
      email: "",
    },
  });

  console.log(
    "Hook form render",
  );

  return (
    <form
      onSubmit={handleSubmit(
        console.log,
      )}
    >
      <input
        {...register(
          "firstName",
          {
            required:
              "First name is required.",
          },
        )}
      />

      <input
        {...register(
          "lastName",
          {
            required:
              "Last name is required.",
          },
        )}
      />

      <input
        type="email"
        {...register(
          "email",
          {
            required:
              "Email is required.",
          },
        )}
      />

      {errors.email && (
        <p>
          {errors.email.message}
        </p>
      )}

      <p>
        Dirty:{" "}
        {String(isDirty)}
      </p>

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

This form subscribes to:

errors
isDirty

Changing from pristine to dirty may cause a render.

Changing an error may cause a render.

But every later character does not necessarily require parent state to be updated merely to display the input value.

Simplified render diagrams

Controlled parent form

Character entered
      ↓
React state update
      ↓
Parent form render
      ↓
Children evaluated
      ↓
DOM reconciliation

React Hook Form native input

Character entered
      ↓
Native DOM value changes
      ↓
RHF handler updates
internal field state
      ↓
Relevant subscribed state changed?
       /             \
     No               Yes
      ↓                ↓
No parent render   Consumer render
required for value

Formik versus controlled React versus React Hook Form

Area	Manual controlled form	Formik-style form	React Hook Form
Native input value	React state	Central form state	Usually native DOM
Change wiring	Manual	Library handlers	`register()`
Touched state	Manual	Built in	Built in
Dirty state	Manual	Built in	Built in
Validation	Manual	Library/schema	Rules/resolver
Rerender strategy	State and component boundaries	Central state plus optimizations	Registration and subscriptions
Controlled widgets	Natural	Natural	Usually `Controller`
Native input boilerplate	Higher	Medium	Lower
Debugging values	Direct React state	Central state	Library methods/subscriptions

This is a conceptual comparison, not a universal performance ranking.

When performance optimization matters

Optimize when users experience:

Delayed typing
Input cursor lag
Slow dropdown opening
Long validation pauses
Noticeable step transitions
Freezing during dynamic-field changes
Excessive network requests
Large delays before error messages

Do not optimize because a console printed ten render messages in a tiny form.

User-visible responsiveness is the real goal.

Senior engineer performance checklist

1. Keep rapidly changing state
   close to the component that needs it.

2. Subscribe only to values
   required for rendering.

3. Avoid watch() on the complete
   form unless necessary.

4. Select validation timing
   based on UX and schema cost.

5. Debounce and cancel
   asynchronous checks.

6. Use native registered inputs
   where they fit.

7. Split large forms into
   logical components or steps.

8. Profile before memoizing.

9. Measure production builds.

10. Optimize user-visible delays,
    not theoretical render counts.

Advantages of React Hook Form performance architecture

Native inputs can retain their values
Parent state is not required for every keystroke
Form state can be subscription-based
Field-level APIs support isolation
Large native-input forms can use less React state wiring
Validation timing is configurable
Controlled components remain supported when needed

Disadvantages and trade-offs

Architecture is less obvious than plain useState
Broad watch() usage can reduce benefits
Controlled components still rerender
Resolver validation can still be expensive
Incorrect component structure can create unnecessary renders
Performance claims require measurement
Debugging uncontrolled values may initially feel unfamiliar

Common beginner mistakes

Believing every render is a bug

Renders are a normal part of React.

The question is:

Is the render causing
noticeable unnecessary work?

Wrapping everything in `React.memo()`

Memoization has a cost and adds complexity.

Use it where profiling shows repeated expensive renders with stable inputs.

Using `watch()` as a replacement for `getValues()`

Use:

getValues()

when you only need to read a value during a button click.

Use:

watch()

when rendering must react to changes.

Running remote validation on every character

Debounce, cancel stale requests, and perform the final authoritative check during submission.

Choosing a form library only from benchmark charts

Also evaluate:

Team knowledge
TypeScript support
Accessibility patterns
Validation integration
Design-system compatibility
Dynamic arrays
Maintenance
Documentation
Testing
Migration cost

Interview questions

Why can controlled inputs become expensive?

They update React state on every keystroke. If that state is owned by a component rendering a large tree, the tree may perform unnecessary work after each edit.

Does a React rerender recreate the complete DOM?

No. React recalculates component output and then commits the required DOM changes. However, component functions and child calculations may still perform work.

Why can React Hook Form reduce rerenders?

Native inputs can retain their current values, while React Hook Form tracks form state through registration and subscriptions. The parent does not always need to store every character in React state.

Can React Hook Form still rerender frequently?

Yes. Errors, dirty state, validity, submission state, watched values, controlled components, field arrays, and parent updates can all cause renders.

What is the difference between `watch()` and `getValues()` from a performance perspective?

watch() subscribes rendering to value changes. getValues() reads the current value without creating the same reactive subscription.

Should `mode: "onChange"` always be avoided?

No. It can provide useful immediate feedback. Its cost and user experience should be evaluated based on the size and complexity of the form.

Why this evolved

React Hook Form and subscription-based state management improved the performance of many large forms. However, production systems still need to handle workflows that go beyond one page of inputs: multi-step forms, conditional sections, repeatable arrays, file uploads, autosave, and draft recovery. Those requirements lead to enterprise form architectures.

Part 4 Summary

We started by recognizing that the frontend is not a trusted boundary.

React validation
        ↓
Improves user experience

Express validation
        ↓
Protects application logic

Database constraints
        ↓
Protect data integrity

The backend validates:

Structure
Business rules
Database state
Authorization
Tokens and sessions

It then sends a consistent error response:

{
  "success": false,
  "code": "EMAIL_ALREADY_EXISTS",
  "field": "email",
  "message": "An account with this email already exists."
}

The frontend maps that response:

Axios catch
     ↓
error.response.data
     ↓
field = "email"
     ↓
setError("email")
     ↓
errors.email
     ↓
Email error paragraph

Accessibility then connects the visible interface to semantic relationships:

label
  ↓
input
  ↓
aria-invalid
  ↓
aria-describedby
  ↓
error message

Finally, performance depends on architecture rather than slogans.

Controlled input
→ React state on every change

Registered native input
→ DOM retains value
→ Form state updates through subscriptions

The central lessons are:

Frontend validation is for experience; backend validation is for trust.
Error responses should use consistent codes, fields, and messages.
setError() uses registered field paths to create errors such as errors.email.
An error appears only where the UI explicitly renders that error path.
Accessibility requires labels, instructions, keyboard behavior, focus management, and understandable errors.
Rerenders are normal; optimize measured user-visible bottlenecks.
React Hook Form can reduce value-driven renders, but subscriptions and component architecture still matter.

The next part will cover:

Stage 17
Enterprise forms
├── Multi-step forms
├── Dynamic arrays
├── Conditional fields
├── File uploads
├── Debounced validation
├── Autosave
└── Draft recovery

Stage 18
Modern form architecture
├── Folder structure
├── Reusable components
├── Schema organization
├── API layers
├── Toasts
└── Error boundaries

Stage 19
The future of forms
├── Server Actions
├── AI-assisted completion
├── Voice filling
├── OCR
├── Conversational forms
└── Agentic form completion

The Evolution of Web Forms — Part 3

Karthik Reddy — Mon, 24 Aug 2026 06:39:38 +0000

The Evolution of Web Forms — Part 3: React Hook Form, Validation Libraries, and Zod

In Part 2, we learned that React solved the problem of manually updating the DOM.

Instead of writing:

emailError.textContent =
  "Email already exists";

emailInput.setAttribute(
  "aria-invalid",
  "true"
);

React allowed us to describe the interface from state:

<input
  aria-invalid={Boolean(errors.email)}
/>

{errors.email && (
  <p>{errors.email}</p>
)}

However, React did not automatically manage:

Form values
Validation errors
Touched fields
Dirty fields
Submission state
Reset behavior
Dynamic fields
Backend errors
Performance

Developers still had to build those features manually.

That created the need for form-management libraries.

This part covers:

React Hook Form’s philosophy and architecture
React Hook Form’s core APIs
Validation libraries
React Hook Form with Zod and TypeScript

By the end, we will build a production-style registration form using:

React
+
TypeScript
+
React Hook Form
+
Zod
+
An API layer

Stage 9: React Hook Form Deep Dive

React Hook Form is not simply a shorter way to write controlled React forms.

It uses a different architectural philosophy.

A traditional controlled input stores its value in React state:

const [email, setEmail] =
  useState("");

<input
  value={email}
  onChange={(event) => {
    setEmail(event.target.value);
  }}
/>

Every keystroke produces a state update:

User types
    ↓
onChange runs
    ↓
setEmail runs
    ↓
Component renders again
    ↓
Input receives the new value

React Hook Form prefers native, uncontrolled inputs when possible.

<input
  {...register("email")}
/>

The browser stores the current value inside the input element.

React Hook Form registers the input, listens to its events, tracks relevant form state, and reads its value when required. React Hook Form’s official documentation describes register() as the mechanism that connects an input to validation, value tracking, and submission.

Controlled versus uncontrolled inputs

Controlled input

const [email, setEmail] =
  useState("");

<input
  value={email}
  onChange={(event) => {
    setEmail(event.target.value);
  }}
/>

React owns the value.

React state
    ↓
input value

The input cannot independently keep a different value because React continuously supplies it.

Uncontrolled input

<input
  name="email"
  defaultValue=""
/>

The browser owns the current value.

DOM input element
    ↓
current value

React may provide the initial value, but it does not need to update React state after every keystroke.

The current value can be read through:

A ref
FormData
Native form submission
A form-management library

A native uncontrolled input using `useRef`

Before understanding React Hook Form, let us manually build one uncontrolled input.

import {
  FormEvent,
  useRef,
} from "react";

export default function UncontrolledForm() {
  const emailRef =
    useRef<HTMLInputElement>(null);

  function handleSubmit(
    event: FormEvent<HTMLFormElement>
  ) {
    event.preventDefault();

    const email =
      emailRef.current?.value ?? "";

    console.log({ email });
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">
        Email
      </label>

      <input
        id="email"
        name="email"
        type="email"
        ref={emailRef}
      />

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

Notice what is missing:

value={email}
onChange={handleChange}

The browser stores the entered value.

On submission, we access the element through:

emailRef.current

and read:

emailRef.current.value

What is a ref?

A ref gives JavaScript access to an element or another persistent value.

const emailRef =
  useRef<HTMLInputElement>(null);

After React connects the ref to the input:

<input ref={emailRef} />

the ref may contain the actual DOM element:

emailRef.current
        ↓
HTMLInputElement

We can then access browser properties:

emailRef.current?.value;
emailRef.current?.focus();
emailRef.current?.disabled;
emailRef.current?.files;

React Hook Form uses refs as part of registering native inputs.

What does `register()` return?

Consider:

const {
  register,
} = useForm();

const registration =
  register("email");

console.log(registration);

Conceptually, the returned object resembles:

{
  name: "email",
  onChange: function,
  onBlur: function,
  ref: function
}

When we write:

<input
  {...register("email")}
/>

the spread operator applies those properties to the input.

Conceptually, it becomes:

<input
  name="email"
  onChange={registeredOnChange}
  onBlur={registeredOnBlur}
  ref={registeredRef}
/>

React Hook Form can now:

Identify the field by name
Track changes
Track blur events
Access the input element
Read the field value
Run validation
Focus the input after an error
Include the value during submission

Why the field name matters

register("email")

registers a field under the key:

email

The submitted object becomes:

{
  email: "karthik@example.com"
}

A nested field name:

register("address.city")

can produce:

{
  address: {
    city: "Kadapa"
  }
}

An array-style field:

register(
  "experiences.0.company"
)

can produce:

{
  experiences: [
    {
      company: "Example Company"
    }
  ]
}

The name is not merely an HTML detail.

It is the path React Hook Form uses to organize the form data and errors.

React Hook Form’s conceptual architecture

The exact internal implementation can change between versions, so application code should not depend on private internals.

However, the public architecture can be understood conceptually.

                   useForm()
                      ↓
              Form control object
                      ↓
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
Registered fields   Form state    Subscriptions
       ↓              ↓              ↓
name, ref,         errors,        Notify only
events, rules      dirty, etc.    interested UI
       ↓
Native DOM inputs
store current values

When an input changes:

User types
    ↓
Native input value changes
    ↓
Registered onChange runs
    ↓
React Hook Form updates internal field state
    ↓
Validation may run
    ↓
Only subscribed form state is notified

The browser can keep the current input value without requiring the parent component to store that value in React state after every keystroke.

Why fewer rerenders can happen

In a manually controlled form:

User types into email
        ↓
setValues()
        ↓
Form component renders
        ↓
All JSX inside the form is recalculated

With React Hook Form and a native registered input:

User types into email
        ↓
DOM input stores the value
        ↓
React Hook Form records relevant changes
        ↓
Only subscribed form-state consumers
need to update

This does not mean React Hook Form never rerenders.

Rerenders can still happen when:

An error appears or disappears
isDirty changes
isValid changes
A watched value changes
A conditional field is rendered
Submission state changes
A controlled component uses Controller
The parent component rerenders for another reason

The important difference is that the input value does not always need to be copied into parent React state on every keystroke.

React Hook Form’s formState is subscription-oriented, and its documentation notes that returned form state is wrapped with a Proxy so unused state properties can avoid unnecessary work.

Understanding form-state subscriptions

Suppose a component reads:

const {
  formState: {
    errors,
  },
} = useForm();

The component is interested in errors.

If it also reads:

const {
  formState: {
    errors,
    isDirty,
    isSubmitting,
  },
} = useForm();

it is interested in three pieces of form state.

Conceptually:

Component subscribes to:
├── errors
├── isDirty
└── isSubmitting

This is one reason destructuring the state that the component needs is important.

React Hook Form does not eliminate state

A common misunderstanding is:

React Hook Form does not use state.

That is not accurate.

React Hook Form still manages state such as:

errors
dirty fields
touched fields
submission state
validation state
registered fields
default values

The difference is where the state is stored, how it is updated, and which components are notified.

Complete React Hook Form example

Install React Hook Form:

npm install react-hook-form

Create src/App.tsx:

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

interface RegistrationValues {
  username: string;
  email: string;
  password: string;
}

const defaultValues:
  RegistrationValues = {
    username: "",
    email: "",
    password: "",
  };

export default function App() {
  const {
    register,
    handleSubmit,
    reset,
    formState: {
      errors,
      isDirty,
      isSubmitting,
    },
  } =
    useForm<RegistrationValues>({
      defaultValues,
      mode: "onBlur",
    });

  const onSubmit:
    SubmitHandler<
      RegistrationValues
    > = async (values) => {
      await new Promise(
        (resolve) => {
          setTimeout(resolve, 1000);
        }
      );

      console.log(
        "Submitted values:",
        values
      );

      reset();
    };

  console.log(
    "Registration form rendered"
  );

  return (
    <main className="page">
      <form
        className="form"
        onSubmit={
          handleSubmit(onSubmit)
        }
        noValidate
      >
        <h1>Create an account</h1>

        <p>
          {isDirty
            ? "You have unsaved changes."
            : "No changes yet."}
        </p>

        <div className="field">
          <label htmlFor="username">
            Username
          </label>

          <input
            id="username"
            type="text"
            autoComplete="username"
            aria-invalid={Boolean(
              errors.username
            )}
            aria-describedby={
              errors.username
                ? "username-error"
                : undefined
            }
            {...register(
              "username",
              {
                required:
                  "Username is required.",

                minLength: {
                  value: 3,
                  message:
                    "Username must contain at least 3 characters.",
                },

                maxLength: {
                  value: 20,
                  message:
                    "Username cannot exceed 20 characters.",
                },

                pattern: {
                  value:
                    /^[A-Za-z0-9_]+$/,

                  message:
                    "Use only letters, numbers, and underscores.",
                },
              }
            )}
          />

          {errors.username && (
            <p
              id="username-error"
              className="error"
            >
              {
                errors.username
                  .message
              }
            </p>
          )}
        </div>

        <div className="field">
          <label htmlFor="email">
            Email
          </label>

          <input
            id="email"
            type="email"
            autoComplete="email"
            aria-invalid={Boolean(
              errors.email
            )}
            aria-describedby={
              errors.email
                ? "email-error"
                : undefined
            }
            {...register("email", {
              required:
                "Email is required.",

              pattern: {
                value:
                  /^[^\s@]+@[^\s@]+\.[^\s@]+$/,

                message:
                  "Enter a valid email address.",
              },
            })}
          />

          {errors.email && (
            <p
              id="email-error"
              className="error"
            >
              {errors.email.message}
            </p>
          )}
        </div>

        <div className="field">
          <label htmlFor="password">
            Password
          </label>

          <input
            id="password"
            type="password"
            autoComplete="new-password"
            aria-invalid={Boolean(
              errors.password
            )}
            aria-describedby={
              errors.password
                ? "password-error"
                : undefined
            }
            {...register(
              "password",
              {
                required:
                  "Password is required.",

                minLength: {
                  value: 8,
                  message:
                    "Password must contain at least 8 characters.",
                },
              }
            )}
          />

          {errors.password && (
            <p
              id="password-error"
              className="error"
            >
              {
                errors.password
                  .message
              }
            </p>
          )}
        </div>

        <div className="actions">
          <button
            type="button"
            onClick={() => {
              reset();
            }}
            disabled={
              isSubmitting ||
              !isDirty
            }
          >
            Reset
          </button>

          <button
            type="submit"
            disabled={isSubmitting}
          >
            {isSubmitting
              ? "Creating account..."
              : "Register"}
          </button>
        </div>
      </form>
    </main>
  );
}

Add src/index.css:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  background: #f4f4f5;
  font-family:
    Inter,
    Arial,
    sans-serif;
}

button,
input {
  font: inherit;
}

.page {
  min-height: 100vh;
  display: grid;
  place-items: center;
  padding: 24px;
}

.form {
  width: min(100%, 480px);
  display: grid;
  gap: 18px;
  padding: 28px;
  background: white;
  border-radius: 12px;
}

.field {
  display: grid;
  gap: 6px;
}

input {
  width: 100%;
  padding: 10px 12px;
  border: 1px solid #71717a;
  border-radius: 6px;
}

input[aria-invalid="true"] {
  border-color: #b91c1c;
}

.error {
  margin: 0;
  color: #b91c1c;
  font-size: 14px;
}

.actions {
  display: flex;
  justify-content: flex-end;
  gap: 12px;
}

button {
  padding: 10px 14px;
  cursor: pointer;
}

button:disabled {
  cursor: not-allowed;
  opacity: 0.65;
}

Controlled React versus React Hook Form

Controlled form

const [email, setEmail] =
  useState("");

<input
  value={email}
  onChange={(event) => {
    setEmail(event.target.value);
  }}
/>

React Hook Form

<input
  {...register("email")}
/>

Comparison

Concern	Controlled React	React Hook Form
Current native input value	React state	Usually the DOM input
Change handler	Manually written	Supplied by `register()`
Blur handler	Manually written	Supplied by `register()`
Field ref	Manually managed	Supplied by `register()`
Errors	Manually stored	`formState.errors`
Dirty state	Manually calculated	`isDirty`, `dirtyFields`
Touched state	Manually calculated	`touchedFields`
Submission	Manually validated	`handleSubmit()`
Reset	Manually coordinated	`reset()`
Server errors	Manually mapped	`setError()`

Advantages of React Hook Form’s architecture

Less boilerplate for native inputs
Input values do not always require parent state
Built-in dirty and touched tracking
Field-level validation
Nested field support
Better support for large forms
Easy integration with schema validators
Type-safe field names with TypeScript
Built-in focus management for many errors
APIs for server-side errors

Disadvantages

The uncontrolled model may initially feel unfamiliar
register() hides several props inside a spread
Custom controlled components require additional integration
Broad use of watch() can cause more rerenders
Incorrect default values can produce confusing dirty-state behavior
Dynamic forms require careful field naming
Understanding subscriptions is still necessary for optimization

Common beginner mistake: overwriting registered handlers

Consider:

<input
  {...register("email")}
  onChange={handleEmailChange}
/>

The later onChange can replace the handler supplied by register().

A safer approach is to place custom behavior in the registration options:

<input
  {...register("email", {
    onChange: (event) => {
      console.log(
        event.target.value
      );
    },
  })}
/>

Or explicitly compose the handlers.

Common beginner mistake: losing the ref

A reusable input component must forward the supplied ref if it is used with register().

If the ref stops at the React component and never reaches the real input, React Hook Form may not be able to register the element correctly.

Interview question

Why can React Hook Form cause fewer rerenders than a traditional controlled form?

A traditional controlled form usually updates React state after every keystroke.

React Hook Form can let the native input retain its current value while tracking form state through registration, refs, events, and subscriptions. React components then update mainly when subscribed state such as errors, dirty status, watched values, or submission state changes.

Why this evolved

React Hook Form reduced form boilerplate and avoided forcing every native input value through parent React state. However, developers still needed to understand its public APIs for reading values, setting errors, controlling validation, resetting fields, and integrating non-native components.

Stage 10: React Hook Form APIs

React Hook Form exposes many methods.

Do not try to memorize all of them at once.

Instead, organize them by responsibility.

Form creation
└── useForm

Field connection
├── register
├── control
└── Controller

Submission
└── handleSubmit

Read values
├── watch
└── getValues

Change values
└── setValue

Errors and validation
├── setError
├── clearErrors
└── trigger

Reset state
├── reset
└── resetField

Form status
└── formState

The official useForm() hook initializes the form and exposes these methods and state objects.

1. `useForm()`

useForm() creates the form-control system.

const form =
  useForm<RegistrationValues>();

Most applications destructure the required methods:

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

Important `useForm()` options

useForm<RegistrationValues>({
  defaultValues: {
    username: "",
    email: "",
    password: "",
  },

  mode: "onBlur",

  shouldUnregister: false,
});

Important options include:

defaultValues
mode
reValidateMode
resolver
shouldUnregister
criteriaMode
context
disabled

2. `defaultValues`

const defaultValues = {
  username: "",
  email: "",
  password: "",
};

useForm({
  defaultValues,
});

Default values serve as the baseline for:

Initial field values
Reset behavior
Dirty comparison

Default email:
""

Current email:
"karthik@example.com"

isDirty:
true

If the current value returns to the default:

Current email:
""

isDirty:
false

Use consistent values.

For text inputs, prefer:

email: ""

instead of:

email: undefined

Asynchronous default values

When editing existing data, default values may come from an API.

useForm<UserFormValues>({
  defaultValues: async () => {
    const response =
      await fetch("/api/me");

    if (!response.ok) {
      throw new Error(
        "Unable to load user"
      );
    }

    return response.json();
  },
});

For externally loaded data, reset() is also commonly used after the data arrives.

3. `mode`

mode controls when initial validation runs.

useForm({
  mode: "onSubmit",
});

Common modes include:

Mode	Validation timing
`onSubmit`	When the user submits
`onBlur`	When the user leaves a field
`onChange`	As the value changes
`onTouched`	After initial interaction
`all`	Blur and change interactions

Example:

useForm({
  mode: "onBlur",
});

This provides a balanced experience:

User types
    ↓
No immediate interruption
    ↓
User leaves field
    ↓
Validate field

Using onChange can provide immediate feedback, but it may also create more validation work and a noisier user experience.

4. `shouldUnregister`

Imagine a conditional field:

{hasCompany && (
  <input
    {...register(
      "companyName"
    )}
  />
)}

When companyName disappears, should its value remain in the form?

With the default preservation-oriented behavior:

shouldUnregister: false

an unmounted field can remain represented in form data.

With:

shouldUnregister: true

an unmounted field is removed from registration and its value is not retained in the same way. React Hook Form documents shouldUnregister as controlling whether fields are removed after unmount.

Use true when hidden fields should behave like native fields that no longer exist.

Use false when temporarily hidden steps should preserve their data.

5. `register()`

register() connects a native field to React Hook Form.

<input
  {...register("email")}
/>

It can also accept validation rules:

<input
  {...register("email", {
    required:
      "Email is required.",

    pattern: {
      value:
        /^[^\s@]+@[^\s@]+\.[^\s@]+$/,

      message:
        "Enter a valid email address.",
    },
  })}
/>

Common registration rules include:

register("age", {
  required: "Age is required.",

  min: {
    value: 18,
    message:
      "You must be at least 18.",
  },

  max: {
    value: 100,
    message:
      "Enter a valid age.",
  },

  valueAsNumber: true,

  validate: (value) => {
    return (
      Number.isInteger(value) ||
      "Age must be a whole number."
    );
  },
});

Custom validation with `validate`

register("username", {
  validate: {
    noSpaces: (value) => {
      return (
        !value.includes(" ") ||
        "Username cannot contain spaces."
      );
    },

    notAdmin: (value) => {
      return (
        value.toLowerCase() !==
          "admin" ||
        "This username is reserved."
      );
    },
  },
});

A validation function can return:

true

when valid, or:

an error message

when invalid.

6. `handleSubmit()`

handleSubmit() coordinates validation and submission.

<form
  onSubmit={
    handleSubmit(onSubmit)
  }
>

The success callback receives validated values:

const onSubmit = (
  values: RegistrationValues
) => {
  console.log(values);
};

You can also provide an invalid callback:

const onInvalid = (
  errors: FieldErrors<
    RegistrationValues
  >
) => {
  console.log(
    "Validation failed:",
    errors
  );
};

<form
  onSubmit={
    handleSubmit(
      onSubmit,
      onInvalid
    )
  }
/>

The process is:

Native submit event
       ↓
handleSubmit
       ↓
Run validation
      / \
   Invalid Valid
      ↓     ↓
 onInvalid onSubmit

handleSubmit() validates before invoking the success callback and can pass typed form data to it.

7. `watch()`

watch() subscribes to value changes.

const country =
  watch("country");

You can use the value for conditional rendering:

{country === "india" && (
  <input
    {...register("state")}
  />
)}

Watch multiple fields:

const [
  password,
  confirmPassword,
] = watch([
  "password",
  "confirmPassword",
]);

Watch the entire form:

const values = watch();

Be careful with broad watches.

Watching the complete form means the component may update for changes across all watched fields.

React Hook Form documents watch() as a method for observing field values and rendering conditional UI.

`watch()` versus `getValues()`

These methods can return similar data but have different purposes.

const email =
  watch("email");

watch() subscribes to changes.

const email =
  getValues("email");

getValues() reads the current value without subscribing the component to value changes. React Hook Form specifically documents getValues() as reading values without subscribing to rerenders.

Use:

watch()

when the UI must react to changes.

Use:

getValues()

when you only need a value at a particular moment.

8. `getValues()`

Read every field:

const values =
  getValues();

Read one field:

const email =
  getValues("email");

Read several fields:

const [
  email,
  username,
] = getValues([
  "email",
  "username",
]);

Example:

function handlePreview() {
  const values =
    getValues();

  console.log(
    "Preview:",
    values
  );
}

<button
  type="button"
  onClick={handlePreview}
>
  Preview current data
</button>

9. `setValue()`

setValue() updates a field programmatically.

setValue(
  "email",
  "karthik@example.com"
);

Options can update related form state:

setValue(
  "email",
  "karthik@example.com",
  {
    shouldValidate: true,
    shouldDirty: true,
    shouldTouch: true,
  }
);

React Hook Form supports using setValue() to change a registered value while optionally validating it or marking it dirty and touched.

Production examples for `setValue()`

Selecting an address

function selectAddress(
  address: Address
) {
  setValue(
    "address.city",
    address.city,
    {
      shouldDirty: true,
    }
  );
}

OCR document extraction

setValue(
  "fullName",
  extractedDocument.name,
  {
    shouldDirty: true,
    shouldValidate: true,
  }
);

Choosing a suggested username

setValue(
  "username",
  suggestedUsername,
  {
    shouldDirty: true,
    shouldValidate: true,
  }
);

10. `setError()`

setError() manually inserts an error.

setError("email", {
  type: "server",
  message:
    "Email already exists.",
});

The result becomes available through:

errors.email

You can then render:

{errors.email && (
  <p>
    {errors.email.message}
  </p>
)}

React Hook Form explicitly supports setError() for custom and server-side validation errors.

Root-level errors

Not every error belongs to one field.

setError("root.server", {
  type: "server",
  message:
    "The service is temporarily unavailable.",
});

Display it:

{errors.root?.server && (
  <p role="alert">
    {
      errors.root.server
        .message
    }
  </p>
)}

Examples of root errors:

Server unavailable
Unknown registration failure
Payment provider failure
Session expired
Too many requests
Unexpected response

11. `clearErrors()`

Clear one error:

clearErrors("email");

Clear multiple errors:

clearErrors([
  "email",
  "username",
]);

Clear all errors:

clearErrors();

React Hook Form documents clearErrors() as clearing one, several, or all current errors without itself rerunning validation.

Example:

<input
  {...register("email", {
    onChange: () => {
      clearErrors(
        "root.server"
      );
    },
  })}
/>

Use this when a global server error should disappear after the user begins correcting the form.

Do not clear a field error merely to make the UI look valid.

The value should still be revalidated when appropriate.

12. `reset()`

Reset the complete form:

reset();

Reset with new values:

reset({
  username: "karthik",
  email:
    "karthik@example.com",
  password: "",
});

This can be useful after fetching existing data:

useEffect(() => {
  if (user) {
    reset({
      username:
        user.username,
      email:
        user.email,
      password: "",
    });
  }
}, [user, reset]);

React Hook Form’s reset() API can restore values and form-state properties such as errors, touched fields, and dirty fields according to its supplied options.

Reset while preserving selected state

reset(
  {
    username: "",
    email: "",
    password: "",
  },
  {
    keepErrors: true,
    keepDirty: true,
  }
);

Use preservation options carefully.

After a successful registration, the common behavior is:

reset();

After an API refresh, you may intentionally preserve dirty user edits.

13. `resetField()`

Reset only one field:

resetField("email");

Reset to a new default value:

resetField("email", {
  defaultValue:
    "new@example.com",
});

Optionally preserve state:

resetField("email", {
  keepError: true,
  keepDirty: true,
  keepTouched: true,
});

React Hook Form documents resetField() as resetting one field’s value and state independently of the complete form.

14. `trigger()`

trigger() manually runs validation.

Validate the entire form:

const isValid =
  await trigger();

Validate one field:

const emailIsValid =
  await trigger("email");

Validate several fields:

const credentialsAreValid =
  await trigger([
    "email",
    "password",
  ]);

React Hook Form notes that trigger() is particularly useful when one field depends on another.

Multi-step form example

async function goToNextStep() {
  const stepIsValid =
    await trigger([
      "firstName",
      "lastName",
      "email",
    ]);

  if (!stepIsValid) {
    return;
  }

  setCurrentStep(2);
}

Only move forward when the current step is valid.

15. `control`

control is the internal public control object used by advanced React Hook Form APIs.

const {
  control,
} = useForm();

You normally pass it to:

Controller
useController
useWatch
useFieldArray
useFormState

Do not directly modify control.

React Hook Form documents control as the object used to register and coordinate components with the form system.

16. `Controller`

Native HTML inputs work well with register().

However, some UI components are controlled components.

They may expose an API such as:

<RolePicker
  value={role}
  onChange={setRole}
/>

They do not expose a native input ref in the way register() expects.

Controller connects these components to React Hook Form.

<Controller
  name="role"
  control={control}
  render={({
    field,
    fieldState,
  }) => (
    <RolePicker
      value={field.value}
      onChange={field.onChange}
      onBlur={field.onBlur}
      error={
        fieldState.error
          ?.message
      }
    />
  )}
/>

Controller supplies:

field
├── name
├── value
├── onChange
├── onBlur
├── ref
└── disabled

fieldState
├── error
├── invalid
├── isDirty
└── isTouched

React Hook Form’s documentation places isTouched on an individual controller field’s fieldState.

Important correction: `isTouched` versus `touchedFields`

There is no commonly used top-level:

formState.isTouched

Instead, React Hook Form provides:

formState.touchedFields

for the collection of touched fields.

For one controlled field, Controller provides:

fieldState.isTouched

Conceptually:

Whole form:
touchedFields.email

One Controller field:
fieldState.isTouched

17. `resolver`

A resolver connects React Hook Form to an external validation library.

useForm({
  resolver:
    zodResolver(schema),
});

The resolver:

Receives the form values.
Passes them to the validation library.
Receives validation results.
Converts errors into React Hook Form’s error structure.
Returns validated or transformed values.

React Hook Form’s resolver package supports several schema and validation libraries, including Zod, Yup, Valibot, and Vest.

We will implement this fully in Stage 12.

18. `formState`

const {
  formState,
} = useForm();

Common properties include:

const {
  errors,
  isDirty,
  dirtyFields,
  touchedFields,
  isSubmitting,
  isValid,
  isSubmitted,
  isSubmitSuccessful,
  submitCount,
  defaultValues,
} = formState;

React Hook Form documents formState as the source of current errors, dirty status, touched fields, submission status, and validity.

`errors`

errors.email

Possible shape:

{
  type: "required",
  message:
    "Email is required.",
  ref: HTMLInputElement
}

Render:

{errors.email && (
  <p>
    {errors.email.message}
  </p>
)}

`isDirty`

isDirty

Indicates whether the form currently differs from its default values.

<button
  disabled={!isDirty}
>
  Save changes
</button>

`dirtyFields`

dirtyFields

Identifies individual changed fields.

Example:

{
  email: true,
  address: {
    city: true
  }
}

Use it for:

Autosaving selected fields
Showing changed-field indicators
Building partial update requests
Warning about unsaved changes

`touchedFields`

touchedFields

Tracks fields that have been interacted with according to the form’s event lifecycle.

Example:

{
  email: true,
  password: true
}

`isSubmitting`

isSubmitting

Becomes true while an asynchronous submit callback is running.

<button
  disabled={isSubmitting}
>
  {isSubmitting
    ? "Saving..."
    : "Save"}
</button>

`isValid`

isValid

Represents whether the form currently satisfies its configured validation rules.

Its usefulness depends on the chosen validation mode.

For example:

useForm({
  mode: "onChange",
});

can keep validity more continuously updated, but it also runs validation more frequently.

`defaultValues`

The configured default values are also available through form state.

formState.defaultValues

This can be useful when comparing or displaying original values.

Complete API playground

The following example demonstrates:

useForm
register
handleSubmit
watch
setValue
getValues
setError
clearErrors
reset
resetField
trigger
control
Controller
errors
isDirty
dirtyFields
touchedFields
fieldState.isTouched
isSubmitting
isValid
defaultValues
shouldUnregister
mode

Create src/App.tsx:

import {
  Controller,
  SubmitHandler,
  useForm,
} from "react-hook-form";

interface ProfileFormValues {
  displayName: string;
  email: string;
  country: string;
  state: string;
  role: string;
  newsletter: boolean;
}

const defaultValues:
  ProfileFormValues = {
    displayName: "",
    email: "",
    country: "",
    state: "",
    role: "",
    newsletter: false,
  };

interface RolePickerProps {
  value: string;
  onChange: (
    value: string
  ) => void;
  onBlur: () => void;
  disabled?: boolean;
}

function RolePicker({
  value,
  onChange,
  onBlur,
  disabled,
}: RolePickerProps) {
  const roles = [
    "student",
    "developer",
    "designer",
  ];

  return (
    <div
      className="role-picker"
      role="radiogroup"
      aria-label="Role"
      onBlur={(event) => {
        if (
          !event.currentTarget
            .contains(
              event.relatedTarget
            )
        ) {
          onBlur();
        }
      }}
    >
      {roles.map((role) => {
        const selected =
          value === role;

        return (
          <button
            key={role}
            type="button"
            role="radio"
            aria-checked={
              selected
            }
            disabled={disabled}
            onClick={() => {
              onChange(role);
            }}
          >
            {selected
              ? "✓ "
              : ""}
            {role}
          </button>
        );
      })}
    </div>
  );
}

export default function App() {
  const {
    register,
    handleSubmit,
    watch,
    getValues,
    setValue,
    setError,
    clearErrors,
    reset,
    resetField,
    trigger,
    control,
    formState: {
      errors,
      isDirty,
      dirtyFields,
      touchedFields,
      isSubmitting,
      isValid,
      defaultValues:
        activeDefaultValues,
    },
  } =
    useForm<ProfileFormValues>({
      defaultValues,
      mode: "onBlur",
      shouldUnregister: true,
    });

  const selectedCountry =
    watch("country");

  const onSubmit:
    SubmitHandler<
      ProfileFormValues
    > = async (values) => {
      clearErrors("root.server");

      await new Promise(
        (resolve) => {
          setTimeout(resolve, 1000);
        }
      );

      if (
        values.email
          .toLowerCase() ===
        "existing@example.com"
      ) {
        setError("email", {
          type: "server",
          message:
            "This email is already registered.",
        });

        return;
      }

      console.log(
        "Submitted profile:",
        values
      );

      reset(values);
    };

  async function validateIdentity() {
    const identityIsValid =
      await trigger([
        "displayName",
        "email",
      ]);

    alert(
      identityIsValid
        ? "Identity fields are valid."
        : "Correct the identity fields."
    );
  }

  function previewValues() {
    const values =
      getValues();

    alert(
      JSON.stringify(
        values,
        null,
        2
      )
    );
  }

  return (
    <main className="page">
      <form
        className="form"
        onSubmit={
          handleSubmit(onSubmit)
        }
        noValidate
      >
        <h1>Edit profile</h1>

        <section className="status">
          <p>
            Form dirty:{" "}
            <strong>
              {String(isDirty)}
            </strong>
          </p>

          <p>
            Form valid:{" "}
            <strong>
              {String(isValid)}
            </strong>
          </p>
        </section>

        <div className="field">
          <label htmlFor="displayName">
            Display name
          </label>

          <input
            id="displayName"
            aria-invalid={Boolean(
              errors.displayName
            )}
            aria-describedby={
              errors.displayName
                ? "displayName-error"
                : undefined
            }
            {...register(
              "displayName",
              {
                required:
                  "Display name is required.",

                minLength: {
                  value: 2,
                  message:
                    "Display name must contain at least 2 characters.",
                },
              }
            )}
          />

          {errors.displayName && (
            <p
              id="displayName-error"
              className="error"
            >
              {
                errors.displayName
                  .message
              }
            </p>
          )}
        </div>

        <div className="field">
          <label htmlFor="email">
            Email
          </label>

          <input
            id="email"
            type="email"
            aria-invalid={Boolean(
              errors.email
            )}
            aria-describedby={
              errors.email
                ? "email-error"
                : undefined
            }
            {...register("email", {
              required:
                "Email is required.",

              pattern: {
                value:
                  /^[^\s@]+@[^\s@]+\.[^\s@]+$/,

                message:
                  "Enter a valid email address.",
              },

              onChange: () => {
                clearErrors(
                  "root.server"
                );
              },
            })}
          />

          {errors.email && (
            <p
              id="email-error"
              className="error"
            >
              {errors.email.message}
            </p>
          )}
        </div>

        <div className="field">
          <label htmlFor="country">
            Country
          </label>

          <select
            id="country"
            {...register(
              "country",
              {
                required:
                  "Country is required.",
              }
            )}
          >
            <option value="">
              Select a country
            </option>

            <option value="india">
              India
            </option>

            <option value="usa">
              United States
            </option>

            <option value="uk">
              United Kingdom
            </option>
          </select>

          {errors.country && (
            <p className="error">
              {
                errors.country
                  .message
              }
            </p>
          )}
        </div>

        {selectedCountry ===
          "india" && (
          <div className="field">
            <label htmlFor="state">
              State
            </label>

            <input
              id="state"
              {...register(
                "state",
                {
                  required:
                    "State is required for India.",
                }
              )}
            />

            {errors.state && (
              <p className="error">
                {
                  errors.state
                    .message
                }
              </p>
            )}
          </div>
        )}

        <Controller
          name="role"
          control={control}
          rules={{
            required:
              "Select a role.",
          }}
          render={({
            field,
            fieldState,
          }) => (
            <div className="field">
              <span>Role</span>

              <RolePicker
                value={
                  field.value
                }
                onChange={
                  field.onChange
                }
                onBlur={
                  field.onBlur
                }
                disabled={
                  field.disabled
                }
              />

              <p>
                Role touched:{" "}
                {String(
                  fieldState
                    .isTouched
                )}
              </p>

              {fieldState.error && (
                <p className="error">
                  {
                    fieldState.error
                      .message
                  }
                </p>
              )}
            </div>
          )}
        />

        <label>
          <input
            type="checkbox"
            {...register(
              "newsletter"
            )}
          />

          Receive development
          updates
        </label>

        {errors.root?.server && (
          <p
            className="error"
            role="alert"
          >
            {
              errors.root.server
                .message
            }
          </p>
        )}

        <div className="button-grid">
          <button
            type="button"
            onClick={() => {
              setValue(
                "displayName",
                "Karthik",
                {
                  shouldDirty:
                    true,
                  shouldTouch:
                    true,
                  shouldValidate:
                    true,
                }
              );
            }}
          >
            Use suggested name
          </button>

          <button
            type="button"
            onClick={previewValues}
          >
            Preview values
          </button>

          <button
            type="button"
            onClick={() => {
              setError(
                "root.server",
                {
                  type: "manual",
                  message:
                    "This is a demonstration server error.",
                }
              );
            }}
          >
            Simulate server error
          </button>

          <button
            type="button"
            onClick={() => {
              clearErrors();
            }}
          >
            Clear errors
          </button>

          <button
            type="button"
            onClick={() => {
              resetField("email");
            }}
          >
            Reset email
          </button>

          <button
            type="button"
            onClick={
              validateIdentity
            }
          >
            Validate identity
          </button>

          <button
            type="button"
            onClick={() => {
              reset();
            }}
          >
            Reset form
          </button>
        </div>

        <button
          type="submit"
          disabled={isSubmitting}
        >
          {isSubmitting
            ? "Saving..."
            : "Save profile"}
        </button>

        <details>
          <summary>
            Debug form state
          </summary>

          <pre>
            {JSON.stringify(
              {
                dirtyFields,
                touchedFields,
                activeDefaultValues,
              },
              null,
              2
            )}
          </pre>
        </details>
      </form>
    </main>
  );
}

Common React Hook Form mistakes

Mistake 1: Using both `register()` and `Controller`

Bad:

<Controller
  name="email"
  control={control}
  render={({ field }) => (
    <input
      {...field}
      {...register("email")}
    />
  )}
/>

The field is registered twice.

Use either:

register("email")

or:

<Controller
  name="email"
  control={control}
/>

for that integration.

Mistake 2: Using `Controller` for every native input

This works, but it gives up some of the simplicity of uncontrolled native registration.

For a standard input, prefer:

<input
  {...register("email")}
/>

Use Controller when the component genuinely needs controlled integration.

Mistake 3: Calling `watch()` for everything

const values = watch();

This is convenient, but it causes the component to care about every form value.

Watch only what the UI requires:

const country =
  watch("country");

Mistake 4: Omitting default values

Without a reliable baseline, dirty-state comparisons and reset behavior can become confusing.

Prefer:

useForm({
  defaultValues: {
    email: "",
    password: "",
  },
});

Mistake 5: Treating `getValues()` as reactive

This does not subscribe:

const email =
  getValues("email");

The component will not automatically rerender merely because that email changes.

Use:

const email =
  watch("email");

when rendering depends on the current value.

Interview questions

What does `register()` do?

It connects an input to React Hook Form by supplying the field name, event handlers, and ref required for value tracking, validation, touched state, focus management, and submission.

What is the difference between `watch()` and `getValues()`?

watch() subscribes to value changes and can cause reactive UI updates.

getValues() reads current values without subscribing to future changes.

When should you use `Controller`?

Use Controller for controlled third-party or custom components that communicate through value, onChange, and related props instead of exposing a native input ref compatible with register().

What is the difference between `reset()` and `resetField()`?

reset() resets the complete form.

resetField() resets one registered field and its selected state.

Why this evolved

React Hook Form provided form-state management, but developers still needed a maintainable way to define complex validation rules. Inline rules worked for small forms, but large forms required reusable, testable validation schemas.

Stage 11: Validation Libraries

Validation can be written manually.

function validateEmail(
  email: string
) {
  if (!email.trim()) {
    return "Email is required.";
  }

  if (
    !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(
      email
    )
  ) {
    return "Enter a valid email.";
  }

  return undefined;
}

This is reasonable for one field.

But production validation often includes:

Nested objects
Arrays
Optional fields
Conditional fields
Transformations
Cross-field rules
Runtime type checking
Reusable frontend and backend rules
TypeScript inference
Structured error paths

TypeScript types do not validate runtime data

Consider:

interface User {
  name: string;
  age: number;
}

This helps while writing TypeScript.

But an API may return:

{
  "name": 123,
  "age": "twenty"
}

TypeScript interfaces do not run in the browser or server after compilation.

This assertion:

const user =
  responseData as User;

does not validate anything.

It only tells TypeScript:

Trust me. Treat this as User.

A runtime validation library actually checks the value.

Manual validation

Complete manual schema-like validator

interface RegistrationInput {
  username: string;
  email: string;
  password: string;
  confirmPassword: string;
}

type RegistrationErrors =
  Partial<
    Record<
      keyof RegistrationInput,
      string
    >
  >;

interface ValidationSuccess {
  success: true;
  data: RegistrationInput;
}

interface ValidationFailure {
  success: false;
  errors:
    RegistrationErrors;
}

type ValidationResult =
  | ValidationSuccess
  | ValidationFailure;

function validateRegistration(
  input: unknown
): ValidationResult {
  if (
    typeof input !==
      "object" ||
    input === null
  ) {
    return {
      success: false,
      errors: {
        username:
          "Invalid registration data.",
      },
    };
  }

  const candidate =
    input as Record<
      string,
      unknown
    >;

  const errors:
    RegistrationErrors = {};

  const username =
    typeof candidate.username ===
    "string"
      ? candidate.username.trim()
      : "";

  const email =
    typeof candidate.email ===
    "string"
      ? candidate.email
          .trim()
          .toLowerCase()
      : "";

  const password =
    typeof candidate.password ===
    "string"
      ? candidate.password
      : "";

  const confirmPassword =
    typeof candidate
      .confirmPassword ===
    "string"
      ? candidate
          .confirmPassword
      : "";

  if (!username) {
    errors.username =
      "Username is required.";
  } else if (
    username.length < 3
  ) {
    errors.username =
      "Username must contain at least 3 characters.";
  }

  if (!email) {
    errors.email =
      "Email is required.";
  } else if (
    !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(
      email
    )
  ) {
    errors.email =
      "Enter a valid email address.";
  }

  if (password.length < 8) {
    errors.password =
      "Password must contain at least 8 characters.";
  }

  if (
    confirmPassword !==
    password
  ) {
    errors.confirmPassword =
      "Passwords do not match.";
  }

  if (
    Object.keys(errors).length >
    0
  ) {
    return {
      success: false,
      errors,
    };
  }

  return {
    success: true,
    data: {
      username,
      email,
      password,
      confirmPassword,
    },
  };
}

This works.

But we manually implemented:

Unknown-data checking
String checking
Trimming
Error collection
Error paths
Result types
Cross-field validation
Data transformation

A schema library standardizes this work.

Yup

Yup is a runtime schema builder that supports validation, parsing, transformations, nested objects, and interdependent rules. Its official repository describes it as an object-schema system for runtime parsing and validation.

Install:

npm install yup

Example:

import * as yup from "yup";

const registrationSchema =
  yup
    .object({
      username:
        yup
          .string()
          .trim()
          .required(
            "Username is required."
          )
          .min(
            3,
            "Username must contain at least 3 characters."
          ),

      email:
        yup
          .string()
          .trim()
          .lowercase()
          .email(
            "Enter a valid email address."
          )
          .required(
            "Email is required."
          ),

      password:
        yup
          .string()
          .required(
            "Password is required."
          )
          .min(
            8,
            "Password must contain at least 8 characters."
          ),

      confirmPassword:
        yup
          .string()
          .required(
            "Confirm your password."
          )
          .oneOf(
            [
              yup.ref(
                "password"
              ),
            ],
            "Passwords do not match."
          ),
    })
    .required();

type RegistrationInput =
  yup.InferType<
    typeof registrationSchema
  >;

Validate:

try {
  const validated =
    await registrationSchema
      .validate(input, {
        abortEarly: false,
      });

  console.log(validated);
} catch (error) {
  if (
    error instanceof
    yup.ValidationError
  ) {
    console.log(
      error.inner
    );
  }
}

Yup advantages

Mature ecosystem
Expressive transformations
Strong history with Formik
Nested and conditional rules
TypeScript inference
Async validation support

Yup disadvantages

Some APIs depend heavily on chained transformations
Input/output behavior can require careful understanding
Conditional schemas can become difficult to read
Teams focused on TypeScript-first APIs may prefer alternatives

Zod

Zod is a TypeScript-first runtime validation library with static type inference.

Its schemas can validate values ranging from primitives to complex nested objects, and its current official documentation identifies Zod 4 as stable.

Install:

npm install zod

Example:

import { z } from "zod";

const registrationSchema =
  z
    .object({
      username:
        z
          .string()
          .trim()
          .min(
            1,
            "Username is required."
          )
          .min(
            3,
            "Username must contain at least 3 characters."
          ),

      email:
        z
          .string()
          .trim()
          .email(
            "Enter a valid email address."
          )
          .transform(
            (email) =>
              email.toLowerCase()
          ),

      password:
        z
          .string()
          .min(
            8,
            "Password must contain at least 8 characters."
          ),

      confirmPassword:
        z.string(),
    })
    .refine(
      (values) =>
        values.password ===
        values.confirmPassword,
      {
        path: [
          "confirmPassword",
        ],
        message:
          "Passwords do not match.",
      }
    );

type RegistrationInput =
  z.input<
    typeof registrationSchema
  >;

type RegistrationOutput =
  z.output<
    typeof registrationSchema
  >;

`parse()`

const validated =
  registrationSchema.parse(
    input
  );

If validation fails, parse() throws a Zod error.

`safeParse()`

const result =
  registrationSchema
    .safeParse(input);

if (!result.success) {
  console.log(
    result.error
  );
} else {
  console.log(
    result.data
  );
}

safeParse() returns a discriminated result rather than requiring a try/catch.

Validation result
      /       \
 success      failure
    ↓            ↓
 result.data  result.error

Zod advantages

TypeScript-first API
Static type inference
Runtime validation
Structured error paths
Transformations
Nested schemas
Cross-field validation
Wide integration ecosystem
Convenient safeParse() result
Suitable for client and server boundaries

Zod disadvantages

Schemas can become large
Complex transformations may create different input and output types
Cross-field validation requires deliberate error paths
Large client bundles may matter in extremely size-sensitive applications
A schema does not replace business or database validation

Valibot

Valibot is a modular TypeScript schema library designed around type safety, tree shaking, and smaller client bundles. Its official documentation emphasizes that unused schema actions can be removed by bundlers because of its modular API.

Install:

npm install valibot

Example:

import * as v from "valibot";

const registrationSchema =
  v.pipe(
    v.object({
      username:
        v.pipe(
          v.string(),
          v.trim(),
          v.nonEmpty(
            "Username is required."
          ),
          v.minLength(
            3,
            "Username must contain at least 3 characters."
          )
        ),

      email:
        v.pipe(
          v.string(),
          v.trim(),
          v.email(
            "Enter a valid email address."
          ),
          v.toLowerCase()
        ),

      password:
        v.pipe(
          v.string(),
          v.minLength(
            8,
            "Password must contain at least 8 characters."
          )
        ),

      confirmPassword:
        v.string(),
    }),

    v.forward(
      v.partialCheck(
        [
          [
            "password",
          ],
          [
            "confirmPassword",
          ],
        ],
        (input) =>
          input.password ===
          input.confirmPassword,
        "Passwords do not match."
      ),
      [
        "confirmPassword",
      ]
    )
  );

type RegistrationInput =
  v.InferInput<
    typeof registrationSchema
  >;

type RegistrationOutput =
  v.InferOutput<
    typeof registrationSchema
  >;

Validate:

const result =
  v.safeParse(
    registrationSchema,
    input
  );

if (result.success) {
  console.log(
    result.output
  );
} else {
  console.log(
    result.issues
  );
}

Valibot schemas run at runtime while also supporting inferred TypeScript types.

Valibot advantages

Modular API
Strong TypeScript inference
Tree-shaking-friendly design
Small client bundles
Runtime transformations
Works across browser and server environments

Valibot disadvantages

More functional and pipeline-oriented syntax
Smaller historical ecosystem than Yup or Zod
Teams familiar with chainable APIs may need adjustment
Advanced cross-field validation can initially look unfamiliar

Vest

Vest takes inspiration from unit-test syntax.

Instead of primarily describing one object schema, you write named validation tests.

Vest’s current documentation describes it as a validation system for workflows that change over time, including focused field validation and protection against outdated asynchronous results.

Install:

npm install vest

Example:

import {
  create,
  enforce,
  test,
} from "vest";

interface RegistrationInput {
  username: string;
  email: string;
  password: string;
  confirmPassword: string;
}

const registrationSuite =
  create(
    (
      data:
        RegistrationInput
    ) => {
      test(
        "username",
        "Username is required.",
        () => {
          enforce(
            data.username
          ).isNotBlank();
        }
      );

      test(
        "username",
        "Username must contain at least 3 characters.",
        () => {
          enforce(
            data.username
          ).longerThanOrEquals(
            3
          );
        }
      );

      test(
        "email",
        "Enter a valid email address.",
        () => {
          enforce(
            data.email
          ).matches(
            /^[^\s@]+@[^\s@]+\.[^\s@]+$/
          );
        }
      );

      test(
        "password",
        "Password must contain at least 8 characters.",
        () => {
          enforce(
            data.password
          ).longerThanOrEquals(
            8
          );
        }
      );

      test(
        "confirmPassword",
        "Passwords do not match.",
        () => {
          enforce(
            data.confirmPassword
          ).equals(
            data.password
          );
        }
      );
    }
  );

Run:

const result =
  registrationSuite.run(
    formData
  );

if (
  result.hasErrors(
    "email"
  )
) {
  console.log(
    result.getError(
      "email"
    )
  );
}

Vest is especially relevant for:

Multi-step forms
Asynchronous field validation
Progressive validation
Conditional workflows
Retaining validation results across focused runs

Vest advantages

Validation reads like tests
Framework-independent
Focused field validation
Stateful validation workflows
Async race-condition support
Useful for multi-step and conditional forms

Vest disadvantages

Different mental model from object schemas
May be unnecessary for simple payload parsing
Form state and data state still require architectural decisions
Less natural when the primary need is a single runtime object schema

Validation-library comparison

Approach	Main style	Type inference	Transformations	Best fit
Manual	Functions and conditions	Manual	Manual	Very small forms
Yup	Chainable object schemas	Yes	Strong	Existing Formik/Yup projects
Zod	TypeScript-first schemas	Strong	Strong	Full-stack TypeScript applications
Valibot	Modular functional pipelines	Strong	Strong	Bundle-sensitive TypeScript applications
Vest	Test-like validation suites	Supported	Different focus	Complex interactive validation workflows

Why Zod became a common choice

Zod fits naturally into TypeScript applications because one schema can provide:

Runtime validation
        +
TypeScript type inference
        +
Structured error paths
        +
Data transformation

Example:

const userSchema =
  z.object({
    name: z.string(),
    age:
      z
        .number()
        .int()
        .positive(),
  });

type User =
  z.infer<
    typeof userSchema
  >;

Without inference, a developer might write the same structure twice:

interface User {
  name: string;
  age: number;
}

const userSchema = {
  // Duplicate definition
};

Duplicated definitions can drift apart.

With inference:

Schema
  ├── validates runtime data
  └── generates TypeScript type

The official resolver integration can infer values from Zod and several other schema libraries.

Sharing frontend and backend schemas

A monorepo may contain:

apps/
├── web/
└── api/

packages/
└── validation/
    └── auth.schema.ts

Shared schema:

import { z } from "zod";

export const registerSchema =
  z.object({
    username:
      z
        .string()
        .trim()
        .min(3),

    email:
      z
        .string()
        .trim()
        .email(),

    password:
      z
        .string()
        .min(8),
  });

export type RegisterInput =
  z.input<
    typeof registerSchema
  >;

Frontend:

resolver:
  zodResolver(
    registerSchema
  )

Backend:

const result =
  registerSchema.safeParse(
    request.body
  );

This reduces accidental rule differences.

However, not every rule should be shared.

The backend may also enforce:

Email uniqueness
Username uniqueness
Database constraints
Authorization
Rate limits
Token validity
Account state
File scanning
Organization membership

Complete Zod validation example

Create validation-demo.ts:

import { z } from "zod";

const registrationSchema =
  z
    .object({
      username:
        z
          .string({
            message:
              "Username must be text.",
          })
          .trim()
          .min(
            1,
            "Username is required."
          )
          .min(
            3,
            "Username must contain at least 3 characters."
          )
          .max(
            20,
            "Username cannot exceed 20 characters."
          )
          .regex(
            /^[A-Za-z0-9_]+$/,
            "Use only letters, numbers, and underscores."
          ),

      email:
        z
          .string({
            message:
              "Email must be text.",
          })
          .trim()
          .email(
            "Enter a valid email address."
          )
          .transform(
            (email) =>
              email.toLowerCase()
          ),

      password:
        z
          .string()
          .min(
            8,
            "Password must contain at least 8 characters."
          )
          .max(
            72,
            "Password cannot exceed 72 characters."
          ),

      confirmPassword:
        z.string(),

      acceptTerms:
        z
          .boolean()
          .refine(
            (accepted) =>
              accepted,
            {
              message:
                "You must accept the terms.",
            }
          ),
    })
    .refine(
      (values) =>
        values.password ===
        values.confirmPassword,
      {
        path: [
          "confirmPassword",
        ],
        message:
          "Passwords do not match.",
      }
    );

type RegistrationInput =
  z.input<
    typeof registrationSchema
  >;

type RegistrationOutput =
  z.output<
    typeof registrationSchema
  >;

const input:
  RegistrationInput = {
    username: "  Karthik_2005  ",
    email:
      "  KARTHIK@EXAMPLE.COM  ",
    password:
      "Password123",
    confirmPassword:
      "Password123",
    acceptTerms: true,
  };

const result =
  registrationSchema
    .safeParse(input);

if (!result.success) {
  const fieldErrors =
    result.error.flatten()
      .fieldErrors;

  console.log(
    "Validation failed:",
    fieldErrors
  );
} else {
  const data:
    RegistrationOutput =
      result.data;

  console.log(
    "Validation succeeded:",
    data
  );
}

Output:

{
  username:
    "Karthik_2005",

  email:
    "karthik@example.com",

  password:
    "Password123",

  confirmPassword:
    "Password123",

  acceptTerms:
    true
}

The schema did more than validate.

It also transformed selected values:

"  KARTHIK@EXAMPLE.COM  "
              ↓
"karthik@example.com"

Common validation mistakes

Mistake 1: Using TypeScript assertions as validation

const data =
  request.body as RegisterInput;

This does not validate the request.

Use:

const result =
  registerSchema
    .safeParse(
      request.body
    );

Mistake 2: Sharing inappropriate rules

The frontend can share format rules.

It cannot safely decide:

Email is unique
User is authorized
Token is valid
Session is active

Those require trusted server-side checks.

Mistake 3: Putting every business rule in one schema

Schemas are useful, but a 1,000-line schema can become difficult to maintain.

Separate:

Structural validation
Business services
Database constraints
Authorization

Mistake 4: Ignoring transformed types

A schema can transform:

string input
    ↓
Date output

or:

string input
    ↓
number output

In those cases:

z.input<typeof schema>

and:

z.output<typeof schema>

may be different.

Interview questions

Why do we need runtime validation when we already have TypeScript?

TypeScript checks source code during development.

It cannot guarantee that runtime values from forms, APIs, files, databases, or external services match the expected types.

Runtime schemas validate actual values.

What is the difference between `parse()` and `safeParse()` in Zod?

parse() returns validated data or throws an error.

safeParse() returns a success-or-failure result object.

Can the same validation schema be used on the frontend and backend?

Yes, structural and format validation can often be shared.

The backend must still enforce trusted business rules such as uniqueness, authorization, token validity, and database constraints.

Why this evolved

Validation libraries made rules reusable and type-safe, but React Hook Form still needed a way to understand their success and error formats. Resolver integrations were created to connect schema validation with form state automatically.

Stage 12: React Hook Form with Zod

React Hook Form manages:

Inputs
Errors
Dirty state
Touched state
Submission state
Reset behavior

Zod manages:

Validation rules
Runtime type safety
Transformations
Cross-field validation
Inferred TypeScript types

The resolver connects them.

React Hook Form
      ↓ values
Zod resolver
      ↓
Zod schema
     / \
 invalid valid
   ↓       ↓
errors    parsed data
   ↓       ↓
formState onSubmit

Install the dependencies

npm install \
  react-hook-form \
  zod \
  @hookform/resolvers

The resolver package officially supports connecting React Hook Form to Zod and inferring schema output types.

Project structure

src/
├── components/
│   └── FormInput.tsx
│
├── features/
│   └── auth/
│       ├── register.api.ts
│       ├── register.schema.ts
│       └── RegisterForm.tsx
│
├── App.tsx
└── index.css

Each file has one responsibility.

register.schema.ts
→ validation contract

register.api.ts
→ network communication

FormInput.tsx
→ reusable presentation

RegisterForm.tsx
→ form behavior and integration

Step 1: Create the Zod schema

Create:

src/features/auth/register.schema.ts

import { z } from "zod";

export const registerSchema =
  z
    .object({
      username:
        z
          .string()
          .trim()
          .min(
            1,
            "Username is required."
          )
          .min(
            3,
            "Username must contain at least 3 characters."
          )
          .max(
            20,
            "Username cannot exceed 20 characters."
          )
          .regex(
            /^[A-Za-z0-9_]+$/,
            "Use only letters, numbers, and underscores."
          ),

      displayName:
        z
          .string()
          .trim()
          .min(
            1,
            "Display name is required."
          )
          .min(
            2,
            "Display name must contain at least 2 characters."
          )
          .max(
            50,
            "Display name cannot exceed 50 characters."
          ),

      email:
        z
          .string()
          .trim()
          .min(
            1,
            "Email is required."
          )
          .email(
            "Enter a valid email address."
          )
          .transform(
            (email) =>
              email.toLowerCase()
          ),

      password:
        z
          .string()
          .min(
            1,
            "Password is required."
          )
          .min(
            8,
            "Password must contain at least 8 characters."
          )
          .max(
            72,
            "Password cannot exceed 72 characters."
          )
          .regex(
            /[A-Z]/,
            "Password must contain an uppercase letter."
          )
          .regex(
            /[a-z]/,
            "Password must contain a lowercase letter."
          )
          .regex(
            /[0-9]/,
            "Password must contain a number."
          ),

      confirmPassword:
        z
          .string()
          .min(
            1,
            "Confirm your password."
          ),

      acceptTerms:
        z
          .boolean()
          .refine(
            (accepted) =>
              accepted,
            {
              message:
                "You must accept the terms.",
            }
          ),
    })
    .refine(
      (values) =>
        values.password ===
        values.confirmPassword,
      {
        path: [
          "confirmPassword",
        ],
        message:
          "Passwords do not match.",
      }
    );

export type RegisterInput =
  z.input<
    typeof registerSchema
  >;

export type RegisterOutput =
  z.output<
    typeof registerSchema
  >;

Why use `z.object()`?

z.object({
  username: z.string(),
  email: z.string(),
});

z.object() describes the expected shape of the complete form.

Registration object
├── username: string
├── displayName: string
├── email: string
├── password: string
├── confirmPassword: string
└── acceptTerms: boolean

If a field has the wrong runtime type, the schema rejects it.

Why use `refine()`?

Field-level methods validate one field.

z.string().min(8)

Password confirmation depends on two fields:

values.password ===
values.confirmPassword

That is a cross-field rule.

.refine(
  (values) =>
    values.password ===
    values.confirmPassword,
  {
    path: [
      "confirmPassword",
    ],
    message:
      "Passwords do not match.",
  }
)

The path is essential.

Without it, the issue may belong to the complete object.

With:

path: [
  "confirmPassword",
]

the error is associated with:

errors.confirmPassword

Step 2: Create the API layer

Create:

src/features/auth/register.api.ts

import type {
  RegisterOutput,
} from "./register.schema";

export interface RegisterResponse {
  success: true;
  message: string;
  data: {
    user: {
      id: string;
      username: string;
      displayName: string;
      email: string;
    };
  };
}

export interface ApiErrorResponse {
  success: false;
  message: string;
  field?: keyof RegisterOutput;
}

export class ApiError extends Error {
  status: number;
  data: ApiErrorResponse;

  constructor(
    status: number,
    data: ApiErrorResponse
  ) {
    super(data.message);

    this.name = "ApiError";
    this.status = status;
    this.data = data;
  }
}

export async function registerUser(
  input: RegisterOutput
): Promise<RegisterResponse> {
  // Replace this demonstration with:
  //
  // const response = await fetch(
  //   "/api/auth/register",
  //   {
  //     method: "POST",
  //     headers: {
  //       "Content-Type":
  //         "application/json",
  //     },
  //     body: JSON.stringify(input),
  //   }
  // );

  await new Promise(
    (resolve) => {
      setTimeout(resolve, 1000);
    }
  );

  if (
    input.email ===
    "existing@example.com"
  ) {
    throw new ApiError(
      409,
      {
        success: false,
        field: "email",
        message:
          "An account with this email already exists.",
      }
    );
  }

  if (
    input.username
      .toLowerCase() ===
    "admin"
  ) {
    throw new ApiError(
      409,
      {
        success: false,
        field: "username",
        message:
          "This username is not available.",
      }
    );
  }

  return {
    success: true,
    message:
      "Registration successful. Check your email to verify your account.",

    data: {
      user: {
        id:
          crypto.randomUUID(),

        username:
          input.username,

        displayName:
          input.displayName,

        email:
          input.email,
      },
    },
  };
}

This mock allows the frontend example to run without a backend.

Later, the mock can be replaced with a real Fetch or Axios request.

Step 3: Create a reusable input

Create:

src/components/FormInput.tsx

import {
  forwardRef,
  InputHTMLAttributes,
} from "react";

interface FormInputProps
  extends InputHTMLAttributes<HTMLInputElement> {
  label: string;
  error?: string;
}

const FormInput =
  forwardRef<
    HTMLInputElement,
    FormInputProps
  >(function FormInput(
    {
      id,
      label,
      error,
      className = "",
      ...inputProps
    },
    ref
  ) {
    if (!id) {
      throw new Error(
        "FormInput requires an id."
      );
    }

    const errorId =
      `${id}-error`;

    return (
      <div className="field">
        <label htmlFor={id}>
          {label}
        </label>

        <input
          id={id}
          ref={ref}
          className={
            className
          }
          aria-invalid={Boolean(
            error
          )}
          aria-describedby={
            error
              ? errorId
              : undefined
          }
          {...inputProps}
        />

        {error && (
          <p
            id={errorId}
            className="error"
          >
            {error}
          </p>
        )}
      </div>
    );
  });

export default FormInput;

Why `forwardRef()` is required

React Hook Form supplies a ref through:

register("email")

Our custom component must pass that ref to the real input.

React Hook Form ref
       ↓
FormInput component
       ↓
forwardRef
       ↓
native <input>

Without forwarding:

<input ref={ref} />

the registration ref would stop at the custom component boundary.

Step 4: Create the registration form

Create:

src/features/auth/RegisterForm.tsx

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

import {
  zodResolver,
} from "@hookform/resolvers/zod";

import FormInput from "../../components/FormInput";

import {
  ApiError,
  registerUser,
} from "./register.api";

import {
  RegisterInput,
  RegisterOutput,
  registerSchema,
} from "./register.schema";

const defaultValues:
  RegisterInput = {
    username: "",
    displayName: "",
    email: "",
    password: "",
    confirmPassword: "",
    acceptTerms: false,
  };

export default function RegisterForm() {
  const {
    register,
    handleSubmit,
    setError,
    clearErrors,
    reset,
    formState: {
      errors,
      isDirty,
      dirtyFields,
      touchedFields,
      isSubmitting,
      isSubmitSuccessful,
    },
  } =
    useForm<
      RegisterInput,
      unknown,
      RegisterOutput
    >({
      defaultValues,
      resolver:
        zodResolver(
          registerSchema
        ),
      mode: "onBlur",
    });

  const onSubmit:
    SubmitHandler<
      RegisterOutput
    > = async (values) => {
      clearErrors("root.server");

      try {
        const response =
          await registerUser(
            values
          );

        console.log(
          "Registration response:",
          response
        );

        reset();

        alert(
          response.message
        );
      } catch (error) {
        if (
          error instanceof
          ApiError
        ) {
          const {
            field,
            message,
          } = error.data;

          if (
            field &&
            field in
              defaultValues
          ) {
            setError(
              field as keyof RegisterInput,
              {
                type: "server",
                message,
              },
              {
                shouldFocus:
                  true,
              }
            );

            return;
          }

          setError(
            "root.server",
            {
              type: "server",
              message,
            }
          );

          return;
        }

        setError(
          "root.server",
          {
            type: "unknown",
            message:
              "Unable to create your account. Try again.",
          }
        );
      }
    };

  return (
    <form
      className="form"
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <header>
        <h1>Create an account</h1>

        <p>
          Learn modern form
          validation with React
          Hook Form and Zod.
        </p>
      </header>

      <FormInput
        id="username"
        label="Username"
        type="text"
        autoComplete="username"
        error={
          errors.username
            ?.message
        }
        {...register(
          "username"
        )}
      />

      <FormInput
        id="displayName"
        label="Display name"
        type="text"
        autoComplete="name"
        error={
          errors.displayName
            ?.message
        }
        {...register(
          "displayName"
        )}
      />

      <FormInput
        id="email"
        label="Email"
        type="email"
        autoComplete="email"
        error={
          errors.email
            ?.message
        }
        {...register(
          "email",
          {
            onChange: () => {
              clearErrors(
                "root.server"
              );
            },
          }
        )}
      />

      <FormInput
        id="password"
        label="Password"
        type="password"
        autoComplete="new-password"
        error={
          errors.password
            ?.message
        }
        {...register(
          "password"
        )}
      />

      <FormInput
        id="confirmPassword"
        label="Confirm password"
        type="password"
        autoComplete="new-password"
        error={
          errors
            .confirmPassword
            ?.message
        }
        {...register(
          "confirmPassword"
        )}
      />

      <div className="field">
        <label className="checkbox">
          <input
            type="checkbox"
            aria-invalid={Boolean(
              errors.acceptTerms
            )}
            aria-describedby={
              errors.acceptTerms
                ? "acceptTerms-error"
                : undefined
            }
            {...register(
              "acceptTerms"
            )}
          />

          <span>
            I accept the terms
            and privacy policy.
          </span>
        </label>

        {errors.acceptTerms && (
          <p
            id="acceptTerms-error"
            className="error"
          >
            {
              errors.acceptTerms
                .message
            }
          </p>
        )}
      </div>

      {errors.root?.server && (
        <p
          className="error alert"
          role="alert"
        >
          {
            errors.root.server
              .message
          }
        </p>
      )}

      {isSubmitSuccessful && (
        <p
          className="success"
          role="status"
        >
          The last submission
          completed successfully.
        </p>
      )}

      <button
        type="submit"
        disabled={isSubmitting}
      >
        {isSubmitting
          ? "Creating account..."
          : "Create account"}
      </button>

      <details>
        <summary>
          Development state
        </summary>

        <pre>
          {JSON.stringify(
            {
              isDirty,
              dirtyFields,
              touchedFields,
            },
            null,
            2
          )}
        </pre>
      </details>
    </form>
  );
}

Step 5: Render the form

Create src/App.tsx:

import RegisterForm from "./features/auth/RegisterForm";

export default function App() {
  return (
    <main className="page">
      <RegisterForm />
    </main>
  );
}

Step 6: Add styles

Create or update src/index.css:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  background: #f4f4f5;
  color: #18181b;
  font-family:
    Inter,
    Arial,
    sans-serif;
}

button,
input {
  font: inherit;
}

.page {
  min-height: 100vh;
  display: grid;
  place-items: center;
  padding: 24px;
}

.form {
  width: min(100%, 500px);
  display: grid;
  gap: 18px;
  padding: 28px;
  background: white;
  border-radius: 14px;
  box-shadow:
    0 10px 30px
    rgb(0 0 0 / 8%);
}

.form header {
  display: grid;
  gap: 6px;
}

.form h1,
.form p {
  margin: 0;
}

.field {
  display: grid;
  gap: 6px;
}

input {
  width: 100%;
  padding: 10px 12px;
  border: 1px solid #71717a;
  border-radius: 6px;
}

input:focus {
  outline:
    3px solid
    rgb(59 130 246 / 25%);
  border-color: #2563eb;
}

input[aria-invalid="true"] {
  border-color: #b91c1c;
}

.checkbox {
  display: flex;
  align-items: flex-start;
  gap: 10px;
}

.checkbox input {
  width: auto;
  margin-top: 4px;
}

button {
  padding: 11px 16px;
  border: 0;
  border-radius: 6px;
  background: #18181b;
  color: white;
  cursor: pointer;
}

button:disabled {
  cursor: not-allowed;
  opacity: 0.65;
}

.error {
  color: #b91c1c;
  font-size: 14px;
}

.success {
  color: #15803d;
}

.alert {
  padding: 10px;
  border:
    1px solid
    #b91c1c;
  border-radius: 6px;
  background: #fef2f2;
}

details {
  padding-top: 8px;
}

pre {
  max-width: 100%;
  overflow: auto;
  padding: 12px;
  background: #f4f4f5;
  border-radius: 6px;
  font-size: 12px;
}

Understanding the `useForm` generic types

We used:

useForm<
  RegisterInput,
  unknown,
  RegisterOutput
>()

The three generic positions represent:

useForm<
  Input,
  Context,
  Output
>

The resolver documentation shows this input/context/output form for schemas that transform data.

In our schema:

type RegisterInput =
  z.input<
    typeof registerSchema
  >;

describes values before schema parsing.

type RegisterOutput =
  z.output<
    typeof registerSchema
  >;

describes values after parsing and transformations.

Our email transformation changes:

KARTHIK@EXAMPLE.COM
        ↓
karthik@example.com

The TypeScript type remains a string, but the semantic value is normalized.

For schemas that convert strings into dates or numbers, the input and output TypeScript types may also differ.

What does `zodResolver()` do?

We configure:

resolver:
  zodResolver(
    registerSchema
  )

When the form validates, the resolver conceptually performs:

const result =
  registerSchema
    .safeParse(values);

If successful:

{
  values: result.data,
  errors: {}
}

If unsuccessful, it maps Zod issues into field errors:

{
  values: {},
  errors: {
    email: {
      type:
        "invalid_format",
      message:
        "Enter a valid email address."
    }
  }
}

The exact internal representation should be treated as library implementation detail, but this is the important public flow.

Complete validation data flow

User types into email input
             ↓
register("email") tracks field
             ↓
User blurs field or submits form
             ↓
React Hook Form collects values
             ↓
zodResolver receives values
             ↓
registerSchema validates values
          /             \
       Invalid           Valid
          ↓                ↓
Zod returns issues    Zod returns parsed data
          ↓                ↓
Resolver maps issues  handleSubmit calls
to RHF errors         onSubmit(parsedData)
          ↓                ↓
errors.email          API function runs
          ↓
Error rendered under email

How one error reaches only one input

Suppose Zod produces an issue at:

path: [
  "email",
]

The resolver converts it into:

errors.email

Our component passes:

error={
  errors.email?.message
}

only to the email input:

<FormInput
  id="email"
  error={
    errors.email?.message
  }
/>

The username input reads:

errors.username

The password input reads:

errors.password

Therefore:

errors.email
     ↓
Email FormInput
     ↓
email-error paragraph

It does not automatically appear under every input.

Each component explicitly reads the error path belonging to its own field.

Cross-field error flow

The schema contains:

.refine(
  (values) =>
    values.password ===
    values.confirmPassword,
  {
    path: [
      "confirmPassword",
    ],
    message:
      "Passwords do not match.",
  }
)

The path produces:

errors.confirmPassword

Then:

<FormInput
  error={
    errors.confirmPassword
      ?.message
  }
/>

displays it only under the confirmation field.

Cross-field comparison fails
             ↓
Zod issue path:
confirmPassword
             ↓
errors.confirmPassword
             ↓
Confirmation input error

Frontend validation is not security

The React form can be bypassed.

An attacker can directly send:

POST /api/auth/register
Content-Type: application/json

{
  "username": "",
  "email": "invalid",
  "password": "1"
}

Therefore, the backend must also validate the body.

const result =
  registerSchema
    .safeParse(
      request.body
    );

if (!result.success) {
  return response
    .status(400)
    .json({
      success: false,
      message:
        "Validation failed.",
      errors:
        result.error
          .flatten()
          .fieldErrors,
    });
}

The frontend provides fast feedback.

The backend enforces correctness.

Accessibility review

Our reusable input connects:

<label htmlFor={id}>

to:

<input id={id} />

When an error exists:

aria-invalid={true}

and:

aria-describedby={
  `${id}-error`
}

connect the field to:

<p id={`${id}-error`}>

The relationship is:

Input
aria-describedby="email-error"
              ↓
Error paragraph
id="email-error"

The form also uses:

role="alert"

for a root server error.

Performance notes

Using Zod does not mean validation is free.

Validation still performs work.

Be deliberate about:

mode: "onChange"

for large schemas because it can validate frequently.

A common balanced configuration is:

mode: "onBlur"

or the default submit-first approach.

For expensive asynchronous checks such as username availability:

Debounce requests
Cancel outdated requests
Avoid calling the backend on every raw keystroke
Validate format locally first
Perform the authoritative check on submission

Common React Hook Form + Zod mistakes

Mistake 1: Defining the type separately

Avoid duplicating:

interface RegisterInput {
  username: string;
  email: string;
}

and:

const registerSchema =
  z.object({
    username: z.string(),
    email: z.string(),
  });

Prefer inference:

type RegisterInput =
  z.input<
    typeof registerSchema
  >;

Mistake 2: Forgetting the resolver

Defining a schema does not automatically connect it to the form.

This:

const schema =
  z.object({
    email: z.string(),
  });

does nothing by itself.

Connect it:

useForm({
  resolver:
    zodResolver(schema),
});

Mistake 3: Adding duplicate rules

Avoid unnecessarily validating the same field in both:

register("email", {
  required:
    "Email is required.",
})

and:

z.string().min(
  1,
  "Email is required."
)

When using a resolver, keep the primary validation contract in the schema unless a field-specific registration rule has a deliberate purpose.

Mistake 4: Forgetting the cross-field path

Bad:

.refine(
  passwordsMatch,
  {
    message:
      "Passwords do not match.",
  }
)

The error may be treated as an object-level issue.

Better:

.refine(
  passwordsMatch,
  {
    path: [
      "confirmPassword",
    ],
    message:
      "Passwords do not match.",
  }
)

Mistake 5: Trimming passwords automatically

This may be dangerous:

password:
  z
    .string()
    .trim()

A user’s password may intentionally contain leading or trailing spaces.

Normalize usernames and emails deliberately.

Do not silently transform passwords unless the product explicitly defines that behavior.

Mistake 6: Expecting Zod to check the database

Zod can validate:

Email has a valid format

It cannot independently know:

Email already exists

That requires a database query.

The backend returns the result, and React Hook Form can inject it using:

setError("email", {
  type: "server",
  message:
    "Email already exists.",
});

Senior engineer tips

Keep schemas outside components

Better:

register.schema.ts
RegisterForm.tsx

Avoid redefining a large schema every time the component function runs.

Separate input and output types when transformations exist

type Input =
  z.input<typeof schema>;

type Output =
  z.output<typeof schema>;

This becomes important when converting:

"21"
 ↓
21

or:

"2026-08-24"
      ↓
Date object

Use schemas at trust boundaries

Good validation boundaries include:

Form submission
API request body
Environment variables
External API response
File contents
Queue messages
Database JSON fields

Keep the API layer separate

Avoid placing every Fetch detail inside the form component.

Better:

RegisterForm
    ↓
registerUser()
    ↓
HTTP request

The form handles interface behavior.

The API function handles communication.

Interview questions

What is a resolver in React Hook Form?

A resolver adapts the result of an external validation library into React Hook Form’s expected values-and-errors format.

Why combine React Hook Form and Zod?

React Hook Form manages interactive form state and field registration.

Zod manages runtime data validation, transformations, cross-field rules, and inferred TypeScript types.

How does a Zod error appear in `errors.email`?

Zod produces an issue whose path contains email.

The Zod resolver maps that issue to React Hook Form’s nested error object under the same field path.

What is the difference between `z.input` and `z.output`?

z.input represents the value accepted before schema parsing and transformations.

z.output represents the validated value returned after parsing and transformations.

Should the backend validate again when the frontend uses Zod?

Yes.

Frontend code can be bypassed. The backend must validate every untrusted request independently.

Part 3 summary

React Hook Form changed the form architecture from:

Every keystroke
    ↓
Parent React state
    ↓
Complete form component render

toward:

Native input stores value
    ↓
register connects field
    ↓
Form control tracks state
    ↓
Subscribed UI updates

Its major APIs can be organized as:

Create
└── useForm

Connect
├── register
└── Controller

Read
├── watch
└── getValues

Write
└── setValue

Validate
├── handleSubmit
├── trigger
├── setError
└── clearErrors

Reset
├── reset
└── resetField

Observe
└── formState

Validation libraries then moved rules from scattered conditions into reusable schemas.

Manual conditions
        ↓
Schema validation
        ↓
Runtime safety
        ↓
Type inference
        ↓
Shared validation contracts

Finally, React Hook Form and Zod combined their responsibilities:

React Hook Form
→ form behavior

Zod
→ validation contract

zodResolver
→ connection between them

The next part will cover:

Stage 13
Server-side validation with Express

Stage 14
Mapping backend errors with setError()

Stage 15
Accessible production forms

Stage 16
Form performance and render comparisons

The Evolution of Web Forms — Part 2

Karthik Reddy — Mon, 24 Aug 2026 06:34:36 +0000

The Evolution of Web Forms — Part 2: From React State to Form Libraries

In Part 1, we built forms using:

Plain HTML
Native HTML validation
Vanilla JavaScript validation
AJAX submission

Our AJAX registration form could:

Read input values
Validate fields
Display errors
Submit JSON
Show a loading state
Handle backend errors
Reset after success

That sounds complete.

However, the form had only three fields.

Real production forms may contain dozens of fields, conditional sections, nested objects, uploaded files, dynamic arrays, and multiple validation states.

At that scale, manual DOM manipulation becomes difficult to maintain.

This part covers the next four stages:

The scaling problems of manual forms
React controlled forms
Large React forms and state explosion
The rise of form libraries

The goal is not merely to learn a different syntax.

The goal is to understand why React improved form development—and why React itself did not completely solve the form problem.

Stage 5: Forms Begin to Scale

Consider a simple login form:

Email
Password

It needs only:

2 values
2 possible field errors
1 loading state
1 general server error

Now consider an employee onboarding form.

Personal information
├── First name
├── Last name
├── Email
├── Phone number
├── Date of birth
└── Profile image

Address
├── Country
├── State
├── City
├── Street
└── Postal code

Employment
├── Job title
├── Department
├── Joining date
├── Employment type
└── Manager

Emergency contacts
├── Contact 1
│   ├── Name
│   ├── Relationship
│   └── Phone
└── Contact 2
    ├── Name
    ├── Relationship
    └── Phone

Documents
├── Identity proof
├── Address proof
└── Resume

This is no longer “a few inputs.”

It is a small state-management system.

The hidden state inside every field

An input usually has more state than its value.

For an email field, we may need to know:

{
  value: "karthik@example.com",
  error: "",
  touched: true,
  dirty: true,
  disabled: false,
  validating: false
}

These properties answer different questions.

`value`

What is currently inside the field?

karthik@example.com

`error`

Is the value invalid?

Email already exists.

`touched`

Has the user interacted with and left the field?

The user focused the field and then blurred it.

`dirty`

Is the current value different from its initial value?

Initial value: ""
Current value: "karthik@example.com"

`disabled`

Should the user be allowed to edit it?

`validating`

Is an asynchronous validation request running?

For example:

Checking whether this username is available...

A 20-field form can therefore involve far more than 20 pieces of state.

Problem 1: Repeated DOM queries

In Vanilla JavaScript, we might write:

const firstNameInput =
  document.getElementById("firstName");

const lastNameInput =
  document.getElementById("lastName");

const emailInput =
  document.getElementById("email");

const phoneInput =
  document.getElementById("phone");

const countryInput =
  document.getElementById("country");

const cityInput =
  document.getElementById("city");

Then we also need the corresponding error elements:

const firstNameError =
  document.getElementById("firstName-error");

const lastNameError =
  document.getElementById("lastName-error");

const emailError =
  document.getElementById("email-error");

const phoneError =
  document.getElementById("phone-error");

For every field, we repeatedly:

Find the input.
Find the error element.
Read the value.
Validate the value.
Update accessibility attributes.
Display or remove the error.

Problem 2: Validation duplication

A large form may contain code like:

if (!firstName) {
  showError(
    firstNameInput,
    firstNameError,
    "First name is required."
  );
}

if (!lastName) {
  showError(
    lastNameInput,
    lastNameError,
    "Last name is required."
  );
}

if (!email) {
  showError(
    emailInput,
    emailError,
    "Email is required."
  );
}

if (!phone) {
  showError(
    phoneInput,
    phoneError,
    "Phone number is required."
  );
}

The field names change, but the structure remains almost identical.

Repeated code creates several risks:

A developer forgets to clear one error.
One field uses a different error convention.
Accessibility attributes are applied inconsistently.
A validation rule is updated in one place but not another.
Backend field errors are mapped differently across forms.

Problem 3: Nested values

Simple forms contain flat values:

{
  firstName: "Karthik",
  email: "karthik@example.com"
}

Production forms often contain nested data:

{
  firstName: "Karthik",
  email: "karthik@example.com",
  address: {
    country: "India",
    state: "Andhra Pradesh",
    city: "Kadapa"
  },
  emergencyContact: {
    name: "Example Name",
    relationship: "Parent",
    phone: "9999999999"
  }
}

Reading and updating nested values manually is harder.

formData.address.city = cityInput.value;

Error structures also become nested:

{
  address: {
    city: "City is required."
  }
}

The frontend must connect:

errors.address.city

to:

address.city input

Problem 4: Dynamic fields

Suppose a candidate can add multiple work experiences.

Work Experience 1
├── Company
├── Role
├── Start date
└── End date

+ Add another experience

After clicking the button:

Work Experience 1
Work Experience 2

The final data might look like:

{
  experiences: [
    {
      company: "ABC Technologies",
      role: "Intern",
      startDate: "2025-01-01",
      endDate: "2025-06-01"
    },
    {
      company: "XYZ Software",
      role: "Developer",
      startDate: "2025-07-01",
      endDate: "2026-02-01"
    }
  ]
}

Now the form must support:

Adding fields
Removing fields
Reordering fields
Validating each item
Preserving stable identifiers
Mapping nested errors
Preventing one field's error from appearing under another item

An error might exist at:

experiences[1].company

That means:

The company field
inside the second work-experience item

Manual DOM code becomes increasingly fragile.

Problem 5: Checkboxes

Checkboxes behave differently from text fields.

A single checkbox may represent a Boolean:

<input
  type="checkbox"
  name="acceptTerms"
/>

Result:

{
  acceptTerms: true
}

A checkbox group may represent an array:

Skills:
[x] JavaScript
[x] React
[ ] Angular

Result:

{
  skills: ["javascript", "react"]
}

Developers must decide whether to read:

checkbox.checked

or:

checkbox.value

and then construct the final array correctly.

Problem 6: Radio buttons

Radio buttons usually represent one value from a group.

<label>
  <input
    type="radio"
    name="employmentType"
    value="full-time"
  />

  Full time
</label>

<label>
  <input
    type="radio"
    name="employmentType"
    value="part-time"
  />

  Part time
</label>

The shared name connects the buttons into one group.

The form value should become:

{
  employmentType: "full-time"
}

Validation must treat the group as one logical field, even though it contains multiple HTML inputs.

Problem 7: File uploads

File inputs do not behave exactly like text inputs.

<input
  id="resume"
  name="resume"
  type="file"
/>

The selected value is accessed through:

resumeInput.files

not:

resumeInput.value

A request containing files commonly uses FormData:

const formData = new FormData();

formData.append("firstName", firstName);
formData.append("email", email);
formData.append("resume", resumeInput.files[0]);

File validation may include:

File type
File size
Number of files
Image dimensions
Upload progress
Upload cancellation
Virus-scanning status
Server-side storage failure

Problem 8: Conditional fields

Suppose the form asks:

Are you currently employed?

( ) Yes
( ) No

When the user selects Yes, display:

Current company
Current role
Notice period

When the user selects No, those fields disappear.

Now we must answer:

Should hidden values be preserved?
Should hidden fields still be validated?
Should their errors be removed?
Should they be included in the request?
What happens if the user selects Yes, enters data, and then selects No?

Conditional forms require explicit state rules.

Problem 9: Cross-field validation

Some rules depend on multiple fields.

Password confirmation

password === confirmPassword

Date range

startDate <= endDate

Conditional requirement

If employmentType is "employed",
currentCompany is required.

At least one selection

At least one preferred communication method
must be selected.

Field-by-field validation is no longer enough.

Problem 10: Asynchronous validation

Suppose the user enters:

Username: karthik

The frontend sends:

GET /api/users/check-username?username=karthik

Possible response:

{
  "available": false
}

The form now needs to track:

Idle
  ↓
Checking username...
  ↓
Available or unavailable

What if the user types quickly?

k
ka
kar
kart
karthik

Without debouncing or cancellation, the browser may send many requests.

Responses can also arrive out of order.

Request A: "kart"
Request B: "karthik"

Response B arrives first.
Response A arrives later.

The older response must not replace the newer result.

Complete example: A scaling Vanilla JavaScript form

The following example is still manageable, but notice how much infrastructure is required for only ten fields.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />

    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />

    <title>Large Vanilla JavaScript Form</title>

    <style>
      body {
        max-width: 700px;
        margin: 40px auto;
        padding: 0 16px;
        font-family: Arial, sans-serif;
      }

      form {
        display: grid;
        gap: 18px;
      }

      .row {
        display: grid;
        grid-template-columns: repeat(2, 1fr);
        gap: 16px;
      }

      .field {
        display: flex;
        flex-direction: column;
        gap: 6px;
      }

      .full-width {
        grid-column: 1 / -1;
      }

      input,
      select,
      textarea,
      button {
        padding: 10px;
        font: inherit;
      }

      input[aria-invalid="true"],
      select[aria-invalid="true"],
      textarea[aria-invalid="true"] {
        border: 2px solid #b91c1c;
      }

      .error {
        min-height: 18px;
        margin: 0;
        color: #b91c1c;
        font-size: 14px;
      }

      .success {
        color: #15803d;
      }

      @media (max-width: 600px) {
        .row {
          grid-template-columns: 1fr;
        }
      }
    </style>
  </head>

  <body>
    <h1>Employee onboarding</h1>

    <form id="employee-form" novalidate>
      <div class="row">
        <div class="field">
          <label for="firstName">First name</label>

          <input
            id="firstName"
            name="firstName"
            type="text"
            aria-describedby="firstName-error"
          />

          <p
            id="firstName-error"
            class="error"
          ></p>
        </div>

        <div class="field">
          <label for="lastName">Last name</label>

          <input
            id="lastName"
            name="lastName"
            type="text"
            aria-describedby="lastName-error"
          />

          <p
            id="lastName-error"
            class="error"
          ></p>
        </div>
      </div>

      <div class="row">
        <div class="field">
          <label for="email">Email</label>

          <input
            id="email"
            name="email"
            type="email"
            aria-describedby="email-error"
          />

          <p
            id="email-error"
            class="error"
          ></p>
        </div>

        <div class="field">
          <label for="phone">Phone</label>

          <input
            id="phone"
            name="phone"
            type="tel"
            aria-describedby="phone-error"
          />

          <p
            id="phone-error"
            class="error"
          ></p>
        </div>
      </div>

      <div class="row">
        <div class="field">
          <label for="country">Country</label>

          <select
            id="country"
            name="country"
            aria-describedby="country-error"
          >
            <option value="">Select a country</option>
            <option value="india">India</option>
            <option value="usa">United States</option>
            <option value="uk">United Kingdom</option>
          </select>

          <p
            id="country-error"
            class="error"
          ></p>
        </div>

        <div class="field">
          <label for="city">City</label>

          <input
            id="city"
            name="city"
            type="text"
            aria-describedby="city-error"
          />

          <p
            id="city-error"
            class="error"
          ></p>
        </div>
      </div>

      <div class="row">
        <div class="field">
          <label for="jobTitle">Job title</label>

          <input
            id="jobTitle"
            name="jobTitle"
            type="text"
            aria-describedby="jobTitle-error"
          />

          <p
            id="jobTitle-error"
            class="error"
          ></p>
        </div>

        <div class="field">
          <label for="joiningDate">
            Joining date
          </label>

          <input
            id="joiningDate"
            name="joiningDate"
            type="date"
            aria-describedby="joiningDate-error"
          />

          <p
            id="joiningDate-error"
            class="error"
          ></p>
        </div>
      </div>

      <div class="field">
        <label for="bio">Short biography</label>

        <textarea
          id="bio"
          name="bio"
          rows="4"
          aria-describedby="bio-error"
        ></textarea>

        <p
          id="bio-error"
          class="error"
        ></p>
      </div>

      <div class="field">
        <label>
          <input
            id="acceptTerms"
            name="acceptTerms"
            type="checkbox"
            aria-describedby="acceptTerms-error"
          />

          I accept the employment terms
        </label>

        <p
          id="acceptTerms-error"
          class="error"
        ></p>
      </div>

      <button id="submit-button" type="submit">
        Submit employee details
      </button>

      <p
        id="form-message"
        role="status"
        aria-live="polite"
      ></p>
    </form>

    <script>
      const form =
        document.getElementById("employee-form");

      const submitButton =
        document.getElementById("submit-button");

      const formMessage =
        document.getElementById("form-message");

      const fieldNames = [
        "firstName",
        "lastName",
        "email",
        "phone",
        "country",
        "city",
        "jobTitle",
        "joiningDate",
        "bio",
        "acceptTerms",
      ];

      const fields = Object.fromEntries(
        fieldNames.map((fieldName) => [
          fieldName,
          {
            input: document.getElementById(fieldName),

            error: document.getElementById(
              `${fieldName}-error`
            ),
          },
        ])
      );

      const emailPattern =
        /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

      const phonePattern =
        /^[0-9+\-\s]{8,15}$/;

      function getValues() {
        return {
          firstName:
            fields.firstName.input.value.trim(),

          lastName:
            fields.lastName.input.value.trim(),

          email:
            fields.email.input.value
              .trim()
              .toLowerCase(),

          phone:
            fields.phone.input.value.trim(),

          address: {
            country:
              fields.country.input.value,

            city:
              fields.city.input.value.trim(),
          },

          employment: {
            jobTitle:
              fields.jobTitle.input.value.trim(),

            joiningDate:
              fields.joiningDate.input.value,
          },

          bio:
            fields.bio.input.value.trim(),

          acceptTerms:
            fields.acceptTerms.input.checked,
        };
      }

      function validate(values) {
        const errors = {};

        if (!values.firstName) {
          errors.firstName =
            "First name is required.";
        }

        if (!values.lastName) {
          errors.lastName =
            "Last name is required.";
        }

        if (!values.email) {
          errors.email = "Email is required.";
        } else if (
          !emailPattern.test(values.email)
        ) {
          errors.email =
            "Enter a valid email address.";
        }

        if (!values.phone) {
          errors.phone =
            "Phone number is required.";
        } else if (
          !phonePattern.test(values.phone)
        ) {
          errors.phone =
            "Enter a valid phone number.";
        }

        if (!values.address.country) {
          errors.country =
            "Country is required.";
        }

        if (!values.address.city) {
          errors.city = "City is required.";
        }

        if (!values.employment.jobTitle) {
          errors.jobTitle =
            "Job title is required.";
        }

        if (!values.employment.joiningDate) {
          errors.joiningDate =
            "Joining date is required.";
        }

        if (values.bio.length > 300) {
          errors.bio =
            "Biography cannot exceed 300 characters.";
        }

        if (!values.acceptTerms) {
          errors.acceptTerms =
            "You must accept the terms.";
        }

        return errors;
      }

      function showError(fieldName, message) {
        const field = fields[fieldName];

        if (!field) {
          return;
        }

        field.input.setAttribute(
          "aria-invalid",
          "true"
        );

        field.error.textContent = message;
      }

      function clearError(fieldName) {
        const field = fields[fieldName];

        if (!field) {
          return;
        }

        field.input.setAttribute(
          "aria-invalid",
          "false"
        );

        field.error.textContent = "";
      }

      function clearErrors() {
        fieldNames.forEach(clearError);
      }

      function renderErrors(errors) {
        Object.entries(errors).forEach(
          ([fieldName, message]) => {
            showError(fieldName, message);
          }
        );
      }

      function focusFirstError(errors) {
        const firstFieldName =
          Object.keys(errors)[0];

        fields[firstFieldName]?.input.focus();
      }

      function setSubmitting(isSubmitting) {
        submitButton.disabled = isSubmitting;

        submitButton.textContent = isSubmitting
          ? "Submitting..."
          : "Submit employee details";

        fieldNames.forEach((fieldName) => {
          fields[fieldName].input.disabled =
            isSubmitting;
        });
      }

      form.addEventListener(
        "submit",
        async function (event) {
          event.preventDefault();

          clearErrors();

          formMessage.textContent = "";
          formMessage.className = "";

          const values = getValues();
          const errors = validate(values);

          if (Object.keys(errors).length > 0) {
            renderErrors(errors);
            focusFirstError(errors);
            return;
          }

          setSubmitting(true);

          try {
            await new Promise((resolve) => {
              setTimeout(resolve, 1000);
            });

            console.log(
              "Submitted employee:",
              values
            );

            formMessage.textContent =
              "Employee details submitted.";

            formMessage.className = "success";

            form.reset();
          } catch (error) {
            console.error(error);

            formMessage.textContent =
              "Unable to submit the form.";
          } finally {
            setSubmitting(false);
          }
        }
      );

      fieldNames.forEach((fieldName) => {
        fields[
          fieldName
        ].input.addEventListener(
          "input",
          function () {
            clearError(fieldName);
          }
        );

        fields[
          fieldName
        ].input.addEventListener(
          "change",
          function () {
            clearError(fieldName);
          }
        );
      });
    </script>
  </body>
</html>

This form works.

But ask yourself:

Where is the current form state?
Which fields have been touched?
Which values are dirty?
How do other UI components access the values?
How do we add conditional fields?
How do we reuse this logic?
How do we test DOM-manipulation code?
How do we keep the interface synchronized with the data?

The values live primarily inside the DOM.

JavaScript repeatedly reads the DOM and manually updates it.

DOM stores values
      ↓
JavaScript reads DOM
      ↓
JavaScript performs logic
      ↓
JavaScript manually changes DOM

This is an imperative model.

Imperative UI programming

Imperative code tells the browser exactly what to change.

emailError.textContent =
  "Email already exists.";

emailInput.setAttribute(
  "aria-invalid",
  "true"
);

submitButton.disabled = true;

submitButton.textContent =
  "Submitting...";

We give individual instructions:

Change this text.
Disable this button.
Add this attribute.
Focus this input.
Remove this message.

As the number of possible states increases, it becomes harder to guarantee that every DOM element displays the correct state.

A developer might update the error text but forget to update aria-invalid.

Another might enable the button but forget to re-enable the fields.

The desired solution

Developers wanted to describe the interface as a result of state.

Instead of manually saying:

submitButton.disabled = true;
submitButton.textContent = "Submitting...";

we want to express:

<button disabled={isSubmitting}>
  {isSubmitting
    ? "Submitting..."
    : "Submit"}
</button>

The idea becomes:

State changes
     ↓
UI is recalculated from state
     ↓
Framework updates the required DOM

That declarative approach is one of React's central ideas: rather than manually changing separate DOM elements, developers describe what the UI should look like for the current state.

Advantages of the manual approach

No framework dependency
Direct access to browser APIs
Efficient for small interactions
Full control over individual DOM updates
Works in almost every browser environment
Useful for understanding browser fundamentals

Disadvantages of the manual approach

Repetitive DOM queries
State is scattered across DOM elements and variables
Difficult synchronization
Imperative updates can become inconsistent
Nested and dynamic fields are difficult
Reusability requires custom abstractions
Testing becomes more complicated
Large forms produce substantial boilerplate

Common beginner mistake

A common mistake is believing that React was invented specifically to handle forms.

React is a UI library, not a complete form-management system.

React improves how changing UI is represented, but developers must still design:

Form values
Errors
Touched state
Dirty state
Submission state
Validation timing
Backend error handling

Interview question

What does “declarative UI” mean?

Declarative UI means describing what the interface should look like for the current state instead of manually specifying every DOM operation required to reach that state.

Imperative:

button.disabled = true;
button.textContent = "Saving...";

Declarative:

<button disabled={isSaving}>
  {isSaving ? "Saving..." : "Save"}
</button>

Why this evolved

Manual JavaScript forms worked, but their state was distributed across DOM nodes, variables, and event handlers. As applications became more interactive, developers needed a predictable way to derive the interface from application state. React provided that declarative model.

Stage 6: React Controlled Forms

React allows us to build interfaces from components and state.

Instead of asking:

What DOM element should I manually change?

we ask:

What is the current state?

What should the UI look like for that state?

React then updates the required DOM elements.

Controlled components

Consider this React input:

const [email, setEmail] = useState("");

return (
  <input
    type="email"
    value={email}
    onChange={(event) => {
      setEmail(event.target.value);
    }}
  />
);

This is a controlled input.

React calls an input controlled when its displayed value is driven by React state. The official React documentation also notes that controlled inputs update state on every keystroke.

The three important pieces are:

const [email, setEmail] = useState("");

value={email}

onChange={(event) => {
  setEmail(event.target.value);
}}

Understanding `useState`

const [email, setEmail] = useState("");

This creates:

email
→ current state value

setEmail
→ function used to request a state update

""
→ initial value

Initially:

email = ""

After the user types:

we call:

setEmail("k");

React runs the component again using the new state.

Understanding `value`

value={email}

The input does not independently decide its displayed value.

React state provides the value.

React state
    ↓
input value

If state contains:

karthik@example.com

the input displays:

karthik@example.com

Understanding `onChange`

onChange={(event) => {
  setEmail(event.target.value);
}}

When the user types, the input emits a change event.

React receives the event and reads:

event.target.value

Then state is updated.

User types "k"
       ↓
onChange fires
       ↓
event.target.value is "k"
       ↓
setEmail("k")
       ↓
React component runs again
       ↓
value={email} becomes "k"
       ↓
Input displays "k"

The controlled-input loop

        User types
            ↓
      onChange executes
            ↓
    Update React state
            ↓
 Component function runs
            ↓
React creates next UI description
            ↓
 React updates required DOM
            ↓
      Input shows value

React state becomes the single source of truth.

What does “single source of truth” mean?

Without controlled state, values may exist in several places:

DOM input
JavaScript variable
Validation object
Submission object

Those copies may become inconsistent.

In a controlled form, the current value lives in React state:

const [email, setEmail] = useState("");

The input displays that state:

value={email}

Validation reads that state:

validateEmail(email);

Submission sends that state:

await registerUser({ email });

              React state
             /     |      \
            /      |       \
       Input   Validation  Submission

Setting up the React example

Create a React TypeScript project using Vite:

npm create vite@latest react-form-demo \
  -- --template react-ts

cd react-form-demo

npm install

npm run dev

Replace the contents of src/App.tsx.

Complete controlled registration form

import {
  FormEvent,
  useState,
} from "react";

interface RegistrationValues {
  username: string;
  email: string;
  password: string;
}

interface RegistrationErrors {
  username?: string;
  email?: string;
  password?: string;
  root?: string;
}

const initialValues: RegistrationValues = {
  username: "",
  email: "",
  password: "",
};

function validateRegistration(
  values: RegistrationValues
): RegistrationErrors {
  const errors: RegistrationErrors = {};

  const usernamePattern =
    /^[A-Za-z0-9_]+$/;

  const emailPattern =
    /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

  if (!values.username.trim()) {
    errors.username =
      "Username is required.";
  } else if (
    values.username.trim().length < 3
  ) {
    errors.username =
      "Username must contain at least 3 characters.";
  } else if (
    !usernamePattern.test(
      values.username.trim()
    )
  ) {
    errors.username =
      "Use only letters, numbers, and underscores.";
  }

  if (!values.email.trim()) {
    errors.email = "Email is required.";
  } else if (
    !emailPattern.test(
      values.email.trim()
    )
  ) {
    errors.email =
      "Enter a valid email address.";
  }

  if (!values.password) {
    errors.password =
      "Password is required.";
  } else if (
    values.password.length < 8
  ) {
    errors.password =
      "Password must contain at least 8 characters.";
  }

  return errors;
}

async function registerUser(
  values: RegistrationValues
): Promise<void> {
  await new Promise((resolve) => {
    setTimeout(resolve, 1000);
  });

  if (
    values.email.toLowerCase() ===
    "existing@example.com"
  ) {
    throw new Error(
      "An account with this email already exists."
    );
  }

  console.log(
    "Submitted registration:",
    values
  );
}

export default function App() {
  const [values, setValues] =
    useState<RegistrationValues>(
      initialValues
    );

  const [errors, setErrors] =
    useState<RegistrationErrors>({});

  const [isSubmitting, setIsSubmitting] =
    useState(false);

  const [isSuccess, setIsSuccess] =
    useState(false);

  function handleChange(
    event: React.ChangeEvent<HTMLInputElement>
  ) {
    const { name, value } = event.target;

    setValues((currentValues) => ({
      ...currentValues,
      [name]: value,
    }));

    setErrors((currentErrors) => ({
      ...currentErrors,
      [name]: undefined,
      root: undefined,
    }));

    setIsSuccess(false);
  }

  async function handleSubmit(
    event: FormEvent<HTMLFormElement>
  ) {
    event.preventDefault();

    setIsSuccess(false);

    const validationErrors =
      validateRegistration(values);

    if (
      Object.keys(validationErrors).length >
      0
    ) {
      setErrors(validationErrors);
      return;
    }

    setErrors({});
    setIsSubmitting(true);

    try {
      await registerUser({
        username:
          values.username.trim(),

        email:
          values.email
            .trim()
            .toLowerCase(),

        password:
          values.password,
      });

      setValues(initialValues);
      setIsSuccess(true);
    } catch (error) {
      const message =
        error instanceof Error
          ? error.message
          : "Registration failed.";

      if (
        message.includes(
          "email already exists"
        )
      ) {
        setErrors({
          email: message,
        });
      } else {
        setErrors({
          root: message,
        });
      }
    } finally {
      setIsSubmitting(false);
    }
  }

  console.log(
    "RegistrationForm rendered"
  );

  return (
    <main className="page">
      <form
        className="form"
        onSubmit={handleSubmit}
        noValidate
      >
        <h1>Create an account</h1>

        <div className="field">
          <label htmlFor="username">
            Username
          </label>

          <input
            id="username"
            name="username"
            type="text"
            value={values.username}
            onChange={handleChange}
            disabled={isSubmitting}
            aria-invalid={Boolean(
              errors.username
            )}
            aria-describedby={
              errors.username
                ? "username-error"
                : undefined
            }
          />

          {errors.username && (
            <p
              id="username-error"
              className="error"
            >
              {errors.username}
            </p>
          )}
        </div>

        <div className="field">
          <label htmlFor="email">
            Email
          </label>

          <input
            id="email"
            name="email"
            type="email"
            value={values.email}
            onChange={handleChange}
            disabled={isSubmitting}
            aria-invalid={Boolean(
              errors.email
            )}
            aria-describedby={
              errors.email
                ? "email-error"
                : undefined
            }
          />

          {errors.email && (
            <p
              id="email-error"
              className="error"
            >
              {errors.email}
            </p>
          )}
        </div>

        <div className="field">
          <label htmlFor="password">
            Password
          </label>

          <input
            id="password"
            name="password"
            type="password"
            value={values.password}
            onChange={handleChange}
            disabled={isSubmitting}
            aria-invalid={Boolean(
              errors.password
            )}
            aria-describedby={
              errors.password
                ? "password-error"
                : undefined
            }
          />

          {errors.password && (
            <p
              id="password-error"
              className="error"
            >
              {errors.password}
            </p>
          )}
        </div>

        {errors.root && (
          <p
            className="error"
            role="alert"
          >
            {errors.root}
          </p>
        )}

        {isSuccess && (
          <p
            className="success"
            role="status"
          >
            Registration successful.
          </p>
        )}

        <button
          type="submit"
          disabled={isSubmitting}
        >
          {isSubmitting
            ? "Creating account..."
            : "Register"}
        </button>
      </form>
    </main>
  );
}

Add this to src/index.css:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  font-family:
    Inter,
    Arial,
    sans-serif;
  background: #f5f5f5;
}

button,
input {
  font: inherit;
}

.page {
  min-height: 100vh;
  display: grid;
  place-items: center;
  padding: 24px;
}

.form {
  width: min(100%, 480px);
  display: grid;
  gap: 18px;
  padding: 28px;
  background: white;
  border-radius: 12px;
}

.field {
  display: grid;
  gap: 6px;
}

input {
  width: 100%;
  padding: 10px 12px;
  border: 1px solid #777;
  border-radius: 6px;
}

input[aria-invalid="true"] {
  border-color: #b91c1c;
}

button {
  padding: 11px 16px;
  border: 0;
  border-radius: 6px;
  cursor: pointer;
}

button:disabled {
  cursor: not-allowed;
  opacity: 0.65;
}

.error {
  margin: 0;
  color: #b91c1c;
  font-size: 14px;
}

.success {
  margin: 0;
  color: #15803d;
}

Understanding the form state

The component has four main states.

const [values, setValues] =
  useState(initialValues);

const [errors, setErrors] =
  useState({});

const [isSubmitting, setIsSubmitting] =
  useState(false);

const [isSuccess, setIsSuccess] =
  useState(false);

They represent different concerns.

values
→ What the user entered

errors
→ What is invalid

isSubmitting
→ Whether the request is running

isSuccess
→ Whether the request succeeded

Why use one values object?

We could write:

const [username, setUsername] =
  useState("");

const [email, setEmail] =
  useState("");

const [password, setPassword] =
  useState("");

That works for small forms.

Instead, we use:

const [values, setValues] = useState({
  username: "",
  email: "",
  password: "",
});

This makes it easier to:

Pass all values to validation
Submit the complete object
Reset all fields
Create one shared change handler

Understanding the shared `handleChange`

function handleChange(
  event: React.ChangeEvent<HTMLInputElement>
) {
  const { name, value } = event.target;

  setValues((currentValues) => ({
    ...currentValues,
    [name]: value,
  }));
}

Suppose the email input changes.

<input
  name="email"
  onChange={handleChange}
/>

The event contains:

name = "email"
value = "karthik@example.com"

This:

[name]: value

becomes:

email: "karthik@example.com"

The previous state might be:

{
  username: "karthik",
  email: "",
  password: "Password123"
}

After the update:

{
  username: "karthik",
  email: "karthik@example.com",
  password: "Password123"
}

The spread operator preserves the other fields.

{
  ...currentValues,
  [name]: value
}

Without the spread:

setValues({
  [name]: value,
});

the other values would be removed.

Why must the input have a `name`?

<input
  name="email"
  value={values.email}
  onChange={handleChange}
/>

The handler uses:

event.target.name

to decide which property to update.

The names must match the object keys.

input name="email"
          ↓
values.email

input name="username"
          ↓
values.username

Every keystroke render flow

Suppose the component currently contains:

email = "kar"

The user types:

The flow is:

1. Browser detects input change

2. React calls handleChange()

3. event.target.value is "kart"

4. setValues() requests state update

5. React runs App() again

6. values.email is now "kart"

7. JSX is recalculated

8. React compares previous and next output

9. React updates the input's DOM value

The component function runs again, but React does not necessarily rebuild every real DOM node.

It calculates the next UI description and updates what changed.

Observing renders

The example contains:

console.log(
  "RegistrationForm rendered"
);

Open the browser console and type:

karthik@example.com

You will see the message repeatedly.

That is expected for controlled inputs because each keystroke updates state.

React's current documentation explicitly warns that controlled inputs set state on every keystroke and can become slow when that state causes a large surrounding tree to re-render. It recommends isolating form state or using deferred updates where appropriate.

For a three-field form, this is normally not a problem.

For a large form embedded inside an expensive page, it can matter.

Controlled form render diagram

                         ┌──────────────────┐
                         │ React component  │
                         │      state       │
                         └────────┬─────────┘
                                  │
                                  │ value={values.email}
                                  ▼
                         ┌──────────────────┐
                         │   Email input    │
                         └────────┬─────────┘
                                  │
                                  │ User types
                                  ▼
                         ┌──────────────────┐
                         │    onChange      │
                         └────────┬─────────┘
                                  │
                                  │ setValues(...)
                                  ▼
                         ┌──────────────────┐
                         │ Component runs   │
                         │      again       │
                         └────────┬─────────┘
                                  │
                                  └─────── loop

Why React is better than manual DOM manipulation

In Vanilla JavaScript:

if (error) {
  errorElement.textContent = error;
  input.setAttribute(
    "aria-invalid",
    "true"
  );
} else {
  errorElement.textContent = "";
  input.setAttribute(
    "aria-invalid",
    "false"
  );
}

In React:

<input
  aria-invalid={Boolean(error)}
/>

{error && (
  <p className="error">
    {error}
  </p>
)}

We describe the UI for the current state.

If error exists
→ render error paragraph
→ set aria-invalid to true

If error does not exist
→ do not render paragraph
→ set aria-invalid to false

The UI follows the data.

Advantages of controlled React forms

React state is the source of truth
UI is declarative
Values are immediately available
Conditional fields are easier to express
Inputs can depend on other values
Validation can use current state
Resetting can be done through state
Components can receive values through props
Testing state-driven UI is generally more predictable
TypeScript can describe the form structure

Disadvantages of controlled React forms

Every keystroke updates state
Component functions run again after updates
Considerable boilerplate
Manual error state is still required
Manual touched and dirty tracking may still be required
Large forms can become difficult to optimize
Custom components need careful value and event wiring
Developers can accidentally create controlled/uncontrolled warnings

Common beginner mistake: missing `onChange`

<input value={email} />

The input becomes effectively read-only because React always forces its value to equal email, but nothing updates email.

Correct:

<input
  value={email}
  onChange={(event) => {
    setEmail(event.target.value);
  }}
/>

Common beginner mistake: using `undefined`

An input may start uncontrolled:

const [email, setEmail] =
  useState<string | undefined>(
    undefined
  );

Later it becomes controlled:

setEmail("karthik@example.com");

React may warn that an uncontrolled input became controlled.

For text inputs, use a consistent string initial value:

const [email, setEmail] =
  useState("");

Common beginner mistake: mutating state

Bad:

values.email =
  event.target.value;

setValues(values);

This mutates the existing object.

Better:

setValues((currentValues) => ({
  ...currentValues,
  email: event.target.value,
}));

React state should be treated as immutable.

Common beginner mistake: one handler for incompatible input types

This works for text inputs:

const { name, value } =
  event.target;

But a checkbox needs:

event.target.checked

A file input needs:

event.target.files

A robust handler must understand the input type.

function handleChange(
  event: React.ChangeEvent<HTMLInputElement>
) {
  const {
    name,
    type,
    value,
    checked,
    files,
  } = event.target;

  let nextValue:
    | string
    | boolean
    | FileList
    | null;

  if (type === "checkbox") {
    nextValue = checked;
  } else if (type === "file") {
    nextValue = files;
  } else {
    nextValue = value;
  }

  setValues((currentValues) => ({
    ...currentValues,
    [name]: nextValue,
  }));
}

Even this becomes more complicated when checkbox groups represent arrays.

TypeScript best practice

Define an explicit type for the form values.

interface RegistrationValues {
  username: string;
  email: string;
  password: string;
}

Then type the initial object:

const initialValues:
  RegistrationValues = {
    username: "",
    email: "",
    password: "",
  };

This protects against mistakes such as:

setValues({
  username: "",
  email: "",
  // password accidentally missing
});

Interview question

What is a controlled component?

A controlled form component is an input whose current value is provided by React state and whose changes update that state through an event handler.

const [email, setEmail] =
  useState("");

<input
  value={email}
  onChange={(event) => {
    setEmail(event.target.value);
  }}
/>

Why this evolved

Controlled React forms replaced scattered DOM manipulation with predictable state-driven UI. However, React only provided the building blocks. Developers still had to manually manage values, errors, touched fields, dirty fields, validation, submission, and performance. As forms grew, this created a new kind of complexity.

Stage 7: Large React Forms and State Explosion

A three-field controlled form is clean enough.

A ten-field form begins to reveal the cost.

Imagine tracking:

10 values
10 field errors
10 touched states
10 dirty states
1 loading state
1 success state
1 root error

Depending on the design, that can produce more than 40 logical state values.

Approach 1: Separate state for every field

A beginner may begin like this:

const [firstName, setFirstName] =
  useState("");

const [lastName, setLastName] =
  useState("");

const [email, setEmail] =
  useState("");

const [phone, setPhone] =
  useState("");

const [country, setCountry] =
  useState("");

const [city, setCity] =
  useState("");

const [jobTitle, setJobTitle] =
  useState("");

const [joiningDate, setJoiningDate] =
  useState("");

const [bio, setBio] =
  useState("");

const [acceptTerms, setAcceptTerms] =
  useState(false);

Then errors:

const [firstNameError, setFirstNameError] =
  useState("");

const [lastNameError, setLastNameError] =
  useState("");

const [emailError, setEmailError] =
  useState("");

const [phoneError, setPhoneError] =
  useState("");

Then touched state:

const [emailTouched, setEmailTouched] =
  useState(false);

const [phoneTouched, setPhoneTouched] =
  useState(false);

This quickly becomes unmanageable.

Approach 2: Group related state

A better approach uses objects:

const [values, setValues] =
  useState(initialValues);

const [errors, setErrors] =
  useState({});

const [touched, setTouched] =
  useState({});

const [dirtyFields, setDirtyFields] =
  useState({});

This reduces the number of useState calls.

However, we must still write the logic that updates every object correctly.

Understanding `touched`

A field is usually considered touched after the user focuses and leaves it.

function handleBlur(
  event: React.FocusEvent<
    HTMLInputElement
  >
) {
  const { name } = event.target;

  setTouched((currentTouched) => ({
    ...currentTouched,
    [name]: true,
  }));
}

Then we might show an error only when the field is touched:

{touched.email &&
  errors.email && (
    <p>{errors.email}</p>
  )}

This avoids displaying errors before the user has interacted.

Understanding `dirty`

A field is dirty when its current value differs from its initial value.

Initial email:
""

Current email:
"karthik@example.com"

Dirty:
true

A simple update:

setDirtyFields(
  (currentDirtyFields) => ({
    ...currentDirtyFields,
    [name]:
      value !==
      initialValues[
        name as keyof FormValues
      ],
  })
);

The entire form is dirty if at least one field is dirty.

const isDirty =
  Object.values(
    dirtyFields
  ).some(Boolean);

Why touched and dirty are different

Suppose the user:

Clicks the email input.
Types nothing.
Clicks outside.

Result:

touched = true
dirty = false

Now suppose the user:

Types an email.
Deletes it back to the original empty value.

Depending on the form system's definition:

touched = true
dirty = false

The field was modified, but its current value equals its default value.

Touched answers:

Has the user interacted with the field?

Dirty answers:

Does the current value differ from the default?

Complete large controlled form

The example below manages:

Ten values
Field errors
Touched fields
Dirty fields
Loading state
Success state
Disabled state
Validation on blur
Validation on submit
Form reset

import {
  ChangeEvent,
  FocusEvent,
  FormEvent,
  useState,
} from "react";

interface EmployeeFormValues {
  firstName: string;
  lastName: string;
  email: string;
  phone: string;
  country: string;
  city: string;
  jobTitle: string;
  joiningDate: string;
  bio: string;
  acceptTerms: boolean;
}

type EmployeeFieldName =
  keyof EmployeeFormValues;

type EmployeeErrors =
  Partial<
    Record<EmployeeFieldName, string>
  > & {
    root?: string;
  };

type EmployeeTouched =
  Partial<
    Record<EmployeeFieldName, boolean>
  >;

type EmployeeDirtyFields =
  Partial<
    Record<EmployeeFieldName, boolean>
  >;

const initialValues:
  EmployeeFormValues = {
    firstName: "",
    lastName: "",
    email: "",
    phone: "",
    country: "",
    city: "",
    jobTitle: "",
    joiningDate: "",
    bio: "",
    acceptTerms: false,
  };

const emailPattern =
  /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

const phonePattern =
  /^[0-9+\-\s]{8,15}$/;

function validateField(
  name: EmployeeFieldName,
  value:
    EmployeeFormValues[EmployeeFieldName]
): string | undefined {
  switch (name) {
    case "firstName": {
      if (
        typeof value !== "string" ||
        !value.trim()
      ) {
        return "First name is required.";
      }

      if (value.trim().length < 2) {
        return "First name is too short.";
      }

      return undefined;
    }

    case "lastName": {
      if (
        typeof value !== "string" ||
        !value.trim()
      ) {
        return "Last name is required.";
      }

      return undefined;
    }

    case "email": {
      if (
        typeof value !== "string" ||
        !value.trim()
      ) {
        return "Email is required.";
      }

      if (
        !emailPattern.test(value.trim())
      ) {
        return "Enter a valid email address.";
      }

      return undefined;
    }

    case "phone": {
      if (
        typeof value !== "string" ||
        !value.trim()
      ) {
        return "Phone number is required.";
      }

      if (
        !phonePattern.test(value.trim())
      ) {
        return "Enter a valid phone number.";
      }

      return undefined;
    }

    case "country": {
      if (!value) {
        return "Country is required.";
      }

      return undefined;
    }

    case "city": {
      if (
        typeof value !== "string" ||
        !value.trim()
      ) {
        return "City is required.";
      }

      return undefined;
    }

    case "jobTitle": {
      if (
        typeof value !== "string" ||
        !value.trim()
      ) {
        return "Job title is required.";
      }

      return undefined;
    }

    case "joiningDate": {
      if (!value) {
        return "Joining date is required.";
      }

      return undefined;
    }

    case "bio": {
      if (
        typeof value === "string" &&
        value.trim().length > 300
      ) {
        return "Biography cannot exceed 300 characters.";
      }

      return undefined;
    }

    case "acceptTerms": {
      if (value !== true) {
        return "You must accept the terms.";
      }

      return undefined;
    }

    default: {
      return undefined;
    }
  }
}

function validateForm(
  values: EmployeeFormValues
): EmployeeErrors {
  const errors: EmployeeErrors = {};

  (
    Object.keys(
      values
    ) as EmployeeFieldName[]
  ).forEach((name) => {
    const error = validateField(
      name,
      values[name]
    );

    if (error) {
      errors[name] = error;
    }
  });

  return errors;
}

async function submitEmployee(
  values: EmployeeFormValues
): Promise<void> {
  await new Promise((resolve) => {
    setTimeout(resolve, 1200);
  });

  console.log(
    "Submitted employee:",
    values
  );
}

export default function App() {
  const [values, setValues] =
    useState<EmployeeFormValues>(
      initialValues
    );

  const [errors, setErrors] =
    useState<EmployeeErrors>({});

  const [touched, setTouched] =
    useState<EmployeeTouched>({});

  const [
    dirtyFields,
    setDirtyFields,
  ] =
    useState<EmployeeDirtyFields>(
      {}
    );

  const [isSubmitting, setIsSubmitting] =
    useState(false);

  const [isSuccess, setIsSuccess] =
    useState(false);

  const isDirty =
    Object.values(
      dirtyFields
    ).some(Boolean);

  function updateField<
    TName extends EmployeeFieldName,
  >(
    name: TName,
    value: EmployeeFormValues[TName]
  ) {
    setValues((currentValues) => ({
      ...currentValues,
      [name]: value,
    }));

    setDirtyFields(
      (currentDirtyFields) => ({
        ...currentDirtyFields,
        [name]:
          value !== initialValues[name],
      })
    );

    setErrors((currentErrors) => ({
      ...currentErrors,
      [name]: undefined,
      root: undefined,
    }));

    setIsSuccess(false);
  }

  function handleTextChange(
    event: ChangeEvent<
      HTMLInputElement |
      HTMLTextAreaElement |
      HTMLSelectElement
    >
  ) {
    const name =
      event.target
        .name as EmployeeFieldName;

    updateField(
      name,
      event.target.value
    );
  }

  function handleCheckboxChange(
    event: ChangeEvent<HTMLInputElement>
  ) {
    updateField(
      "acceptTerms",
      event.target.checked
    );
  }

  function handleBlur(
    event: FocusEvent<
      HTMLInputElement |
      HTMLTextAreaElement |
      HTMLSelectElement
    >
  ) {
    const name =
      event.target
        .name as EmployeeFieldName;

    setTouched(
      (currentTouched) => ({
        ...currentTouched,
        [name]: true,
      })
    );

    const fieldError =
      validateField(
        name,
        values[name]
      );

    setErrors(
      (currentErrors) => ({
        ...currentErrors,
        [name]: fieldError,
      })
    );
  }

  function resetForm() {
    setValues(initialValues);
    setErrors({});
    setTouched({});
    setDirtyFields({});
    setIsSuccess(false);
  }

  async function handleSubmit(
    event: FormEvent<HTMLFormElement>
  ) {
    event.preventDefault();

    setIsSuccess(false);

    const nextErrors =
      validateForm(values);

    const allTouched =
      Object.fromEntries(
        Object.keys(values).map(
          (name) => [
            name,
            true,
          ]
        )
      ) as EmployeeTouched;

    setTouched(allTouched);
    setErrors(nextErrors);

    if (
      Object.keys(nextErrors).length >
      0
    ) {
      return;
    }

    setIsSubmitting(true);

    try {
      await submitEmployee({
        ...values,
        firstName:
          values.firstName.trim(),

        lastName:
          values.lastName.trim(),

        email:
          values.email
            .trim()
            .toLowerCase(),

        phone:
          values.phone.trim(),

        city:
          values.city.trim(),

        jobTitle:
          values.jobTitle.trim(),

        bio:
          values.bio.trim(),
      });

      resetForm();
      setIsSuccess(true);
    } catch (error) {
      setErrors({
        root:
          error instanceof Error
            ? error.message
            : "Submission failed.",
      });
    } finally {
      setIsSubmitting(false);
    }
  }

  function getError(
    name: EmployeeFieldName
  ) {
    if (!touched[name]) {
      return undefined;
    }

    return errors[name];
  }

  const firstNameError =
    getError("firstName");

  const lastNameError =
    getError("lastName");

  const emailError =
    getError("email");

  const phoneError =
    getError("phone");

  const countryError =
    getError("country");

  const cityError =
    getError("city");

  const jobTitleError =
    getError("jobTitle");

  const joiningDateError =
    getError("joiningDate");

  const bioError =
    getError("bio");

  const acceptTermsError =
    getError("acceptTerms");

  return (
    <main className="page">
      <form
        className="form"
        onSubmit={handleSubmit}
        noValidate
      >
        <header>
          <h1>Employee onboarding</h1>

          <p>
            Form status:{" "}
            {isDirty
              ? "Unsaved changes"
              : "No changes"}
          </p>
        </header>

        <div className="row">
          <div className="field">
            <label htmlFor="firstName">
              First name
            </label>

            <input
              id="firstName"
              name="firstName"
              value={values.firstName}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                firstNameError
              )}
              aria-describedby={
                firstNameError
                  ? "firstName-error"
                  : undefined
              }
            />

            {firstNameError && (
              <p
                id="firstName-error"
                className="error"
              >
                {firstNameError}
              </p>
            )}
          </div>

          <div className="field">
            <label htmlFor="lastName">
              Last name
            </label>

            <input
              id="lastName"
              name="lastName"
              value={values.lastName}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                lastNameError
              )}
              aria-describedby={
                lastNameError
                  ? "lastName-error"
                  : undefined
              }
            />

            {lastNameError && (
              <p
                id="lastName-error"
                className="error"
              >
                {lastNameError}
              </p>
            )}
          </div>
        </div>

        <div className="row">
          <div className="field">
            <label htmlFor="email">
              Email
            </label>

            <input
              id="email"
              name="email"
              type="email"
              value={values.email}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                emailError
              )}
              aria-describedby={
                emailError
                  ? "email-error"
                  : undefined
              }
            />

            {emailError && (
              <p
                id="email-error"
                className="error"
              >
                {emailError}
              </p>
            )}
          </div>

          <div className="field">
            <label htmlFor="phone">
              Phone
            </label>

            <input
              id="phone"
              name="phone"
              type="tel"
              value={values.phone}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                phoneError
              )}
              aria-describedby={
                phoneError
                  ? "phone-error"
                  : undefined
              }
            />

            {phoneError && (
              <p
                id="phone-error"
                className="error"
              >
                {phoneError}
              </p>
            )}
          </div>
        </div>

        <div className="row">
          <div className="field">
            <label htmlFor="country">
              Country
            </label>

            <select
              id="country"
              name="country"
              value={values.country}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                countryError
              )}
              aria-describedby={
                countryError
                  ? "country-error"
                  : undefined
              }
            >
              <option value="">
                Select a country
              </option>

              <option value="india">
                India
              </option>

              <option value="usa">
                United States
              </option>

              <option value="uk">
                United Kingdom
              </option>
            </select>

            {countryError && (
              <p
                id="country-error"
                className="error"
              >
                {countryError}
              </p>
            )}
          </div>

          <div className="field">
            <label htmlFor="city">
              City
            </label>

            <input
              id="city"
              name="city"
              value={values.city}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                cityError
              )}
              aria-describedby={
                cityError
                  ? "city-error"
                  : undefined
              }
            />

            {cityError && (
              <p
                id="city-error"
                className="error"
              >
                {cityError}
              </p>
            )}
          </div>
        </div>

        <div className="row">
          <div className="field">
            <label htmlFor="jobTitle">
              Job title
            </label>

            <input
              id="jobTitle"
              name="jobTitle"
              value={values.jobTitle}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                jobTitleError
              )}
              aria-describedby={
                jobTitleError
                  ? "jobTitle-error"
                  : undefined
              }
            />

            {jobTitleError && (
              <p
                id="jobTitle-error"
                className="error"
              >
                {jobTitleError}
              </p>
            )}
          </div>

          <div className="field">
            <label htmlFor="joiningDate">
              Joining date
            </label>

            <input
              id="joiningDate"
              name="joiningDate"
              type="date"
              value={values.joiningDate}
              onChange={handleTextChange}
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                joiningDateError
              )}
              aria-describedby={
                joiningDateError
                  ? "joiningDate-error"
                  : undefined
              }
            />

            {joiningDateError && (
              <p
                id="joiningDate-error"
                className="error"
              >
                {joiningDateError}
              </p>
            )}
          </div>
        </div>

        <div className="field">
          <label htmlFor="bio">
            Short biography
          </label>

          <textarea
            id="bio"
            name="bio"
            rows={4}
            value={values.bio}
            onChange={handleTextChange}
            onBlur={handleBlur}
            disabled={isSubmitting}
            aria-invalid={Boolean(
              bioError
            )}
            aria-describedby={
              bioError
                ? "bio-error"
                : "bio-hint"
            }
          />

          <p id="bio-hint">
            {values.bio.length}/300
            characters
          </p>

          {bioError && (
            <p
              id="bio-error"
              className="error"
            >
              {bioError}
            </p>
          )}
        </div>

        <div className="field">
          <label>
            <input
              name="acceptTerms"
              type="checkbox"
              checked={
                values.acceptTerms
              }
              onChange={
                handleCheckboxChange
              }
              onBlur={handleBlur}
              disabled={isSubmitting}
              aria-invalid={Boolean(
                acceptTermsError
              )}
              aria-describedby={
                acceptTermsError
                  ? "acceptTerms-error"
                  : undefined
              }
            />

            I accept the employment terms
          </label>

          {acceptTermsError && (
            <p
              id="acceptTerms-error"
              className="error"
            >
              {acceptTermsError}
            </p>
          )}
        </div>

        {errors.root && (
          <p
            className="error"
            role="alert"
          >
            {errors.root}
          </p>
        )}

        {isSuccess && (
          <p
            className="success"
            role="status"
          >
            Employee details submitted.
          </p>
        )}

        <div className="actions">
          <button
            type="button"
            onClick={resetForm}
            disabled={
              isSubmitting ||
              !isDirty
            }
          >
            Reset
          </button>

          <button
            type="submit"
            disabled={isSubmitting}
          >
            {isSubmitting
              ? "Submitting..."
              : "Submit"}
          </button>
        </div>
      </form>
    </main>
  );
}

Add these styles to the earlier CSS:

.form {
  width: min(100%, 760px);
}

.row {
  display: grid;
  grid-template-columns:
    repeat(2, minmax(0, 1fr));
  gap: 16px;
}

textarea,
select {
  width: 100%;
  padding: 10px 12px;
  font: inherit;
}

.actions {
  display: flex;
  justify-content: flex-end;
  gap: 12px;
}

@media (max-width: 640px) {
  .row {
    grid-template-columns: 1fr;
  }
}

What did we have to build manually?

Although the form is written in React, we manually implemented:

Values
Errors
Touched fields
Dirty fields
Overall dirty status
Validation on blur
Validation on submit
Error visibility rules
Reset behavior
Loading state
Success state
Checkbox handling
Input normalization
Root-level errors

React handled rendering.

React did not design the form architecture for us.

Approximate boilerplate

Depending on formatting and component extraction, a ten-field controlled form can easily require hundreds of lines.

The problem is not merely the number of lines.

The deeper problem is that much of the code is infrastructure rather than business-specific UI.

For example:

setTouched((currentTouched) => ({
  ...currentTouched,
  [name]: true,
}));

setDirtyFields(
  (currentDirtyFields) => ({
    ...currentDirtyFields,
    [name]:
      value !== initialValues[name],
  })
);

setErrors((currentErrors) => ({
  ...currentErrors,
  [name]: undefined,
}));

Every React project began recreating similar logic.

State explosion diagram

Form
├── values
│   ├── firstName
│   ├── lastName
│   ├── email
│   ├── phone
│   └── ...
│
├── errors
│   ├── firstName
│   ├── lastName
│   ├── email
│   └── ...
│
├── touched
│   ├── firstName
│   ├── lastName
│   └── ...
│
├── dirtyFields
│   ├── firstName
│   ├── lastName
│   └── ...
│
├── isDirty
├── isValid
├── isSubmitting
├── isSuccess
└── rootError

Performance problems

Every controlled input change updates React state.

User types
    ↓
setValues()
    ↓
Parent form component runs again
    ↓
All JSX inside the component is recalculated

React is efficient, and rerendering does not mean every DOM element is recreated.

However, a large component may still perform:

Validation calculations
Derived-state calculations
Rendering of many child components
Expensive formatting
Filtering or searching
Conditional layout work

React's documentation recommends moving controlled input state into a smaller component when a large surrounding tree does not need to update on every keystroke.

Common performance mistake

Consider:

export default function CheckoutPage() {
  const [email, setEmail] =
    useState("");

  return (
    <>
      <LargeNavigation />
      <ProductList />
      <Recommendations />
      <CheckoutSummary />

      <input
        value={email}
        onChange={(event) => {
          setEmail(
            event.target.value
          );
        }}
      />
    </>
  );
}

Every email update causes CheckoutPage to run again.

A better structure may isolate the form:

export default function CheckoutPage() {
  return (
    <>
      <LargeNavigation />
      <ProductList />
      <Recommendations />
      <CheckoutSummary />
      <CheckoutForm />
    </>
  );
}

Now the form state lives inside:

function CheckoutForm() {
  const [email, setEmail] =
    useState("");

  return (
    <input
      value={email}
      onChange={(event) => {
        setEmail(
          event.target.value
        );
      }}
    />
  );
}

Only the relevant subtree needs to rerender.

Derived state can become inconsistent

Suppose we store both:

const [values, setValues] =
  useState(initialValues);

const [isDirty, setIsDirty] =
  useState(false);

Now two pieces of state describe related information.

A bug may occur:

setValues(initialValues);

// Forgot:
setIsDirty(false);

The form is empty but still says:

Unsaved changes

Whenever possible, derive state:

const isDirty =
  Object.keys(values).some((key) => {
    const name =
      key as keyof EmployeeFormValues;

    return (
      values[name] !==
      initialValues[name]
    );
  });

However, repeated derivation can also become expensive or complicated for nested values.

Form libraries attempt to manage these relationships consistently.

Advantages of a manual large React form

Complete control
No form-library dependency
Business logic is explicit
Easy to customize unusual behavior
Useful for learning React state deeply
Appropriate for small or highly specialized forms

Disadvantages of a manual large React form

Significant boilerplate
Manual field registration
Manual touched-state tracking
Manual dirty-state tracking
Manual validation timing
Manual nested updates
More opportunities for inconsistent state
Performance optimization becomes the application's responsibility
Dynamic arrays require considerable custom code
Repeating the architecture across many forms wastes time

Senior engineer tip

Do not install a form library merely because a form exists.

A small search form may need only:

const [query, setQuery] =
  useState("");

A library becomes valuable when it removes meaningful complexity.

Good candidates include forms with:

Many fields
Validation schemas
Dynamic arrays
Nested values
Conditional sections
Server errors
Reusable input components
Complex submission states
Performance-sensitive pages

Interview question

What is the difference between touched and dirty?

Touched indicates that the user interacted with a field, commonly by focusing and then leaving it.

Dirty indicates that the current value differs from the field's initial or default value.

A field can be touched without being dirty.

Why this evolved

React made form UI predictable, but developers repeatedly rebuilt the same state-management infrastructure: values, errors, touched fields, dirty fields, validation, resets, and submission handling. Form libraries emerged to standardize and reuse that work.

Stage 8: The Rise of Form Libraries

A form library is not mainly an input-design library.

It generally does not decide:

Your colors
Your border radius
Your labels
Your layout
Your design system

A form library manages form behavior and state.

It commonly provides:

Value management
Error management
Touched tracking
Dirty tracking
Validation
Submission handling
Field registration
Reset behavior
Nested values
Dynamic arrays
Server-error APIs
Performance optimizations

What form libraries abstract

Without a library:

const [values, setValues] =
  useState(initialValues);

const [errors, setErrors] =
  useState({});

const [touched, setTouched] =
  useState({});

const [dirtyFields, setDirtyFields] =
  useState({});

const [isSubmitting, setIsSubmitting] =
  useState(false);

With a library, the API may resemble:

const {
  register,
  handleSubmit,
  formState: {
    errors,
    isDirty,
    dirtyFields,
    touchedFields,
    isSubmitting,
  },
} = useForm();

The complexity has not disappeared.

The library now manages it.

Important distinction: abstraction versus magic

A form library does not make validation, state, or events disappear.

It provides reusable implementations.

Your form
    ↓
Form-library API
    ↓
Internal form state
    ↓
Field subscriptions or React updates
    ↓
Rendered interface

Understanding the manual approach helps you debug the abstraction.

Major React form-library families

This section compares:

Formik
Final Form
React Final Form
React Hook Form
TanStack Form

They solve similar problems but make different architectural choices.

Formik

Formik became one of the most recognizable React form libraries during the late 2010s. Its repository and community resources show active production use and tutorials from 2017 onward.

Formik describes its purpose as handling repetitive form concerns such as values, errors, visited fields, validation, and submission.

Its mental model feels familiar to developers who already understand controlled React state.

Formik's basic approach

Formik stores form state
        ↓
Formik gives values and handlers
        ↓
Inputs receive value/onChange/onBlur
        ↓
State updates
        ↓
Relevant React UI rerenders

Common Formik state includes:

values
errors
touched
dirty
isSubmitting

Install Formik

npm install formik

Complete Formik example

import {
  Form,
  Formik,
} from "formik";

interface RegistrationValues {
  username: string;
  email: string;
  password: string;
}

interface RegistrationErrors {
  username?: string;
  email?: string;
  password?: string;
}

const initialValues:
  RegistrationValues = {
    username: "",
    email: "",
    password: "",
  };

function validate(
  values: RegistrationValues
): RegistrationErrors {
  const errors:
    RegistrationErrors = {};

  if (!values.username.trim()) {
    errors.username =
      "Username is required.";
  } else if (
    values.username.trim().length < 3
  ) {
    errors.username =
      "Username must contain at least 3 characters.";
  }

  if (!values.email.trim()) {
    errors.email =
      "Email is required.";
  } else if (
    !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(
      values.email.trim()
    )
  ) {
    errors.email =
      "Enter a valid email address.";
  }

  if (!values.password) {
    errors.password =
      "Password is required.";
  } else if (
    values.password.length < 8
  ) {
    errors.password =
      "Password must contain at least 8 characters.";
  }

  return errors;
}

export default function FormikExample() {
  return (
    <Formik<RegistrationValues>
      initialValues={initialValues}
      validate={validate}
      onSubmit={async (
        values,
        helpers
      ) => {
        try {
          await new Promise(
            (resolve) => {
              setTimeout(
                resolve,
                1000
              );
            }
          );

          if (
            values.email ===
            "existing@example.com"
          ) {
            helpers.setFieldError(
              "email",
              "Email already exists."
            );

            return;
          }

          console.log(values);

          helpers.resetForm();
        } finally {
          helpers.setSubmitting(
            false
          );
        }
      }}
    >
      {({
        values,
        errors,
        touched,
        dirty,
        isSubmitting,
        handleChange,
        handleBlur,
      }) => (
        <Form
          className="form"
          noValidate
        >
          <h1>Formik registration</h1>

          <p>
            {dirty
              ? "Unsaved changes"
              : "No changes"}
          </p>

          <div className="field">
            <label htmlFor="username">
              Username
            </label>

            <input
              id="username"
              name="username"
              value={
                values.username
              }
              onChange={
                handleChange
              }
              onBlur={handleBlur}
              aria-invalid={Boolean(
                touched.username &&
                  errors.username
              )}
              aria-describedby={
                touched.username &&
                errors.username
                  ? "username-error"
                  : undefined
              }
            />

            {touched.username &&
              errors.username && (
                <p
                  id="username-error"
                  className="error"
                >
                  {errors.username}
                </p>
              )}
          </div>

          <div className="field">
            <label htmlFor="email">
              Email
            </label>

            <input
              id="email"
              name="email"
              type="email"
              value={values.email}
              onChange={
                handleChange
              }
              onBlur={handleBlur}
              aria-invalid={Boolean(
                touched.email &&
                  errors.email
              )}
              aria-describedby={
                touched.email &&
                errors.email
                  ? "email-error"
                  : undefined
              }
            />

            {touched.email &&
              errors.email && (
                <p
                  id="email-error"
                  className="error"
                >
                  {errors.email}
                </p>
              )}
          </div>

          <div className="field">
            <label htmlFor="password">
              Password
            </label>

            <input
              id="password"
              name="password"
              type="password"
              value={
                values.password
              }
              onChange={
                handleChange
              }
              onBlur={handleBlur}
              aria-invalid={Boolean(
                touched.password &&
                  errors.password
              )}
              aria-describedby={
                touched.password &&
                errors.password
                  ? "password-error"
                  : undefined
              }
            />

            {touched.password &&
              errors.password && (
                <p
                  id="password-error"
                  className="error"
                >
                  {errors.password}
                </p>
              )}
          </div>

          <button
            type="submit"
            disabled={isSubmitting}
          >
            {isSubmitting
              ? "Registering..."
              : "Register"}
          </button>
        </Form>
      )}
    </Formik>
  );
}

What Formik removed

We no longer manually created:

const [values, setValues] =
  useState(...);

const [errors, setErrors] =
  useState(...);

const [touched, setTouched] =
  useState(...);

const [isSubmitting, setIsSubmitting] =
  useState(...);

Formik provided:

values
errors
touched
dirty
isSubmitting
handleChange
handleBlur
setFieldError
resetForm

Formik advantages

Familiar controlled-form mental model
Mature API
Strong historical ecosystem
Handles values, errors, touched, and submission
Integrates with schema validators
Supports nested values and arrays
Straightforward for developers familiar with React state

Formik disadvantages

Can produce broad rerenders in large forms
Render-prop code may become deeply nested
Controlled-state architecture can require performance work
Large forms may need field-level optimization
Some modern teams prefer hook-based or subscription-based alternatives

Formik does provide APIs such as hooks and optimized fields, but developers must still understand how form-state changes affect rendering.

Final Form

Final Form is a framework-independent form-state engine.

It is not limited to React.

Its central architectural idea is subscriptions.

Form state changes
        ↓
Which consumers subscribed
to that exact state?
        ↓
Notify only those consumers

A field can subscribe to:

value
error
touched
dirty
active
validating

Instead of forcing every form consumer to react to every change.

React Final Form

React Final Form is the React integration for Final Form.

The official documentation describes React Final Form as a thin React wrapper over the subscription-based Final Form engine, using an Observer-style architecture so components can rerender based on the state they subscribe to.

Its early public issue activity dates to late 2017, placing it in the same broader generation as Formik's initial rise.

Do not confuse the names:

Final Form
→ Core form-state engine

React Final Form
→ React wrapper around Final Form

Install React Final Form

npm install final-form react-final-form

Complete React Final Form example

import {
  Field,
  Form,
} from "react-final-form";

interface RegistrationValues {
  username: string;
  email: string;
  password: string;
}

interface RegistrationErrors {
  username?: string;
  email?: string;
  password?: string;
}

function validate(
  values: RegistrationValues
): RegistrationErrors {
  const errors:
    RegistrationErrors = {};

  if (!values.username) {
    errors.username =
      "Username is required.";
  } else if (
    values.username.length < 3
  ) {
    errors.username =
      "Username must contain at least 3 characters.";
  }

  if (!values.email) {
    errors.email =
      "Email is required.";
  } else if (
    !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(
      values.email
    )
  ) {
    errors.email =
      "Enter a valid email address.";
  }

  if (!values.password) {
    errors.password =
      "Password is required.";
  } else if (
    values.password.length < 8
  ) {
    errors.password =
      "Password must contain at least 8 characters.";
  }

  return errors;
}

export default function ReactFinalFormExample() {
  return (
    <Form<RegistrationValues>
      initialValues={{
        username: "",
        email: "",
        password: "",
      }}
      validate={validate}
      onSubmit={async (
        values,
        form
      ) => {
        await new Promise(
          (resolve) => {
            setTimeout(resolve, 1000);
          }
        );

        if (
          values.email ===
          "existing@example.com"
        ) {
          return {
            email:
              "Email already exists.",
          };
        }

        console.log(values);

        form.restart();

        return undefined;
      }}
      subscription={{
        submitting: true,
        pristine: true,
      }}
      render={({
        handleSubmit,
        submitting,
        pristine,
      }) => (
        <form
          className="form"
          onSubmit={handleSubmit}
          noValidate
        >
          <h1>
            React Final Form
          </h1>

          <Field<string>
            name="username"
            subscription={{
              value: true,
              error: true,
              touched: true,
            }}
          >
            {({
              input,
              meta,
            }) => {
              const showError =
                meta.touched &&
                meta.error;

              return (
                <div className="field">
                  <label htmlFor="username">
                    Username
                  </label>

                  <input
                    {...input}
                    id="username"
                    aria-invalid={Boolean(
                      showError
                    )}
                    aria-describedby={
                      showError
                        ? "username-error"
                        : undefined
                    }
                  />

                  {showError && (
                    <p
                      id="username-error"
                      className="error"
                    >
                      {meta.error}
                    </p>
                  )}
                </div>
              );
            }}
          </Field>

          <Field<string>
            name="email"
            subscription={{
              value: true,
              error: true,
              touched: true,
            }}
          >
            {({
              input,
              meta,
            }) => {
              const showError =
                meta.touched &&
                meta.error;

              return (
                <div className="field">
                  <label htmlFor="email">
                    Email
                  </label>

                  <input
                    {...input}
                    id="email"
                    type="email"
                    aria-invalid={Boolean(
                      showError
                    )}
                    aria-describedby={
                      showError
                        ? "email-error"
                        : undefined
                    }
                  />

                  {showError && (
                    <p
                      id="email-error"
                      className="error"
                    >
                      {meta.error}
                    </p>
                  )}
                </div>
              );
            }}
          </Field>

          <Field<string>
            name="password"
            subscription={{
              value: true,
              error: true,
              touched: true,
            }}
          >
            {({
              input,
              meta,
            }) => {
              const showError =
                meta.touched &&
                meta.error;

              return (
                <div className="field">
                  <label htmlFor="password">
                    Password
                  </label>

                  <input
                    {...input}
                    id="password"
                    type="password"
                    aria-invalid={Boolean(
                      showError
                    )}
                    aria-describedby={
                      showError
                        ? "password-error"
                        : undefined
                    }
                  />

                  {showError && (
                    <p
                      id="password-error"
                      className="error"
                    >
                      {meta.error}
                    </p>
                  )}
                </div>
              );
            }}
          </Field>

          <button
            type="submit"
            disabled={
              submitting ||
              pristine
            }
          >
            {submitting
              ? "Registering..."
              : "Register"}
          </button>
        </form>
      )}
    />
  );
}

Understanding subscriptions

The form subscribes to:

subscription={{
  submitting: true,
  pristine: true,
}}

That means the outer form renderer mainly cares about:

submitting
pristine

The username field subscribes to:

subscription={{
  value: true,
  error: true,
  touched: true,
}}

It does not need every property from the complete form.

React Final Form's <Field> registers itself with the form, subscribes to field state, and receives field callbacks and metadata. The documentation also allows developers to customize exactly which state properties cause field updates.

React Final Form advantages

Fine-grained subscriptions
Framework-independent core
Strong control over rerenders
Rich field metadata
Good support for complex state
Can avoid broad whole-form updates
Clear separation between form engine and React integration

React Final Form disadvantages

Subscription concepts add a learning curve
Render props can create visual nesting
Incorrect subscriptions may hide needed updates
The API may feel more explicit than simpler hook-based approaches
Teams must understand both Final Form and its React adapter

React Hook Form

React Hook Form became prominent during the React Hooks era.

Public repository issues show active use by mid-2019, shortly after Hooks became part of mainstream React development.

Its major architectural difference is that it embraces uncontrolled native inputs while still supporting controlled components when required.

Instead of storing every keystroke in parent React state, React Hook Form can register native inputs and access their values through the DOM and refs.

We will explore its internals deeply in the next part.

Install React Hook Form

npm install react-hook-form

Complete React Hook Form preview

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

interface RegistrationValues {
  username: string;
  email: string;
  password: string;
}

export default function ReactHookFormExample() {
  const {
    register,
    handleSubmit,
    setError,
    reset,
    formState: {
      errors,
      isDirty,
      isSubmitting,
    },
  } =
    useForm<RegistrationValues>({
      defaultValues: {
        username: "",
        email: "",
        password: "",
      },
    });

  const onSubmit:
    SubmitHandler<
      RegistrationValues
    > = async (values) => {
      await new Promise(
        (resolve) => {
          setTimeout(resolve, 1000);
        }
      );

      if (
        values.email ===
        "existing@example.com"
      ) {
        setError("email", {
          type: "server",
          message:
            "Email already exists.",
        });

        return;
      }

      console.log(values);

      reset();
    };

  return (
    <form
      className="form"
      onSubmit={
        handleSubmit(onSubmit)
      }
      noValidate
    >
      <h1>
        React Hook Form
      </h1>

      <p>
        {isDirty
          ? "Unsaved changes"
          : "No changes"}
      </p>

      <div className="field">
        <label htmlFor="username">
          Username
        </label>

        <input
          id="username"
          aria-invalid={Boolean(
            errors.username
          )}
          aria-describedby={
            errors.username
              ? "username-error"
              : undefined
          }
          {...register(
            "username",
            {
              required:
                "Username is required.",

              minLength: {
                value: 3,
                message:
                  "Username must contain at least 3 characters.",
              },
            }
          )}
        />

        {errors.username && (
          <p
            id="username-error"
            className="error"
          >
            {
              errors.username
                .message
            }
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="email">
          Email
        </label>

        <input
          id="email"
          type="email"
          aria-invalid={Boolean(
            errors.email
          )}
          aria-describedby={
            errors.email
              ? "email-error"
              : undefined
          }
          {...register("email", {
            required:
              "Email is required.",

            pattern: {
              value:
                /^[^\s@]+@[^\s@]+\.[^\s@]+$/,

              message:
                "Enter a valid email address.",
            },
          })}
        />

        {errors.email && (
          <p
            id="email-error"
            className="error"
          >
            {errors.email.message}
          </p>
        )}
      </div>

      <div className="field">
        <label htmlFor="password">
          Password
        </label>

        <input
          id="password"
          type="password"
          aria-invalid={Boolean(
            errors.password
          )}
          aria-describedby={
            errors.password
              ? "password-error"
              : undefined
          }
          {...register(
            "password",
            {
              required:
                "Password is required.",

              minLength: {
                value: 8,
                message:
                  "Password must contain at least 8 characters.",
              },
            }
          )}
        />

        {errors.password && (
          <p
            id="password-error"
            className="error"
          >
            {
              errors.password
                .message
            }
          </p>
        )}
      </div>

      <button
        type="submit"
        disabled={isSubmitting}
      >
        {isSubmitting
          ? "Registering..."
          : "Register"}
      </button>
    </form>
  );
}

Notice what is missing:

value={values.email}

onChange={handleChange}

onBlur={handleBlur}

Instead, we write:

{...register("email")}

That is our first hint that React Hook Form uses a different approach.

React Hook Form advantages

Less form boilerplate
Uncontrolled-input support
Fewer broad React state updates
Hook-based API
Strong TypeScript support
Field-level and schema validation
Server-error APIs
Dynamic-field support
Works with controlled components through adapters

React Hook Form disadvantages

Uncontrolled architecture can initially feel unfamiliar
register() spreads several props at once
Custom controlled components require Controller or manual integration
Developers must understand default values and registration
Watching many fields can introduce additional rerenders
Some behavior depends on correct field naming

TanStack Form

TanStack Form is part of the newer generation of form libraries.

Its documentation describes it as framework-agnostic, headless, strongly TypeScript-oriented, and designed for large production forms. It provides adapters for several frontend frameworks, including React.

Unlike React Hook Form's uncontrolled-first philosophy, TanStack Form explicitly embraces controlled form state. Its documentation argues that controlled values can improve predictability, testing, conditional logic, debugging, and non-DOM usage.

This demonstrates an important engineering lesson:

There is no architecture with only advantages.

React Hook Form and TanStack Form make different trade-offs.

Install TanStack Form

npm install @tanstack/react-form

Complete TanStack Form example

import {
  useForm,
} from "@tanstack/react-form";

export default function TanStackFormExample() {
  const form = useForm({
    defaultValues: {
      username: "",
      email: "",
      password: "",
    },

    onSubmit: async ({
      value,
    }) => {
      await new Promise(
        (resolve) => {
          setTimeout(resolve, 1000);
        }
      );

      console.log(value);
    },
  });

  return (
    <form
      className="form"
      noValidate
      onSubmit={(event) => {
        event.preventDefault();
        event.stopPropagation();

        void form.handleSubmit();
      }}
    >
      <h1>TanStack Form</h1>

      <form.Field
        name="username"
        validators={{
          onBlur: ({ value }) => {
            if (!value.trim()) {
              return "Username is required.";
            }

            if (
              value.trim().length < 3
            ) {
              return "Username must contain at least 3 characters.";
            }

            return undefined;
          },
        }}
      >
        {(field) => {
          const error =
            field.state.meta
              .isTouched
              ? field.state.meta
                  .errors[0]
              : undefined;

          return (
            <div className="field">
              <label htmlFor="username">
                Username
              </label>

              <input
                id="username"
                name={field.name}
                value={
                  field.state.value
                }
                onBlur={
                  field.handleBlur
                }
                onChange={(event) => {
                  field.handleChange(
                    event.target.value
                  );
                }}
                aria-invalid={Boolean(
                  error
                )}
                aria-describedby={
                  error
                    ? "username-error"
                    : undefined
                }
              />

              {error && (
                <p
                  id="username-error"
                  className="error"
                >
                  {String(error)}
                </p>
              )}
            </div>
          );
        }}
      </form.Field>

      <form.Field
        name="email"
        validators={{
          onBlur: ({ value }) => {
            if (!value.trim()) {
              return "Email is required.";
            }

            if (
              !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(
                value.trim()
              )
            ) {
              return "Enter a valid email address.";
            }

            return undefined;
          },
        }}
      >
        {(field) => {
          const error =
            field.state.meta
              .isTouched
              ? field.state.meta
                  .errors[0]
              : undefined;

          return (
            <div className="field">
              <label htmlFor="email">
                Email
              </label>

              <input
                id="email"
                name={field.name}
                type="email"
                value={
                  field.state.value
                }
                onBlur={
                  field.handleBlur
                }
                onChange={(event) => {
                  field.handleChange(
                    event.target.value
                  );
                }}
                aria-invalid={Boolean(
                  error
                )}
                aria-describedby={
                  error
                    ? "email-error"
                    : undefined
                }
              />

              {error && (
                <p
                  id="email-error"
                  className="error"
                >
                  {String(error)}
                </p>
              )}
            </div>
          );
        }}
      </form.Field>

      <form.Field
        name="password"
        validators={{
          onBlur: ({ value }) => {
            if (!value) {
              return "Password is required.";
            }

            if (value.length < 8) {
              return "Password must contain at least 8 characters.";
            }

            return undefined;
          },
        }}
      >
        {(field) => {
          const error =
            field.state.meta
              .isTouched
              ? field.state.meta
                  .errors[0]
              : undefined;

          return (
            <div className="field">
              <label htmlFor="password">
                Password
              </label>

              <input
                id="password"
                name={field.name}
                type="password"
                value={
                  field.state.value
                }
                onBlur={
                  field.handleBlur
                }
                onChange={(event) => {
                  field.handleChange(
                    event.target.value
                  );
                }}
                aria-invalid={Boolean(
                  error
                )}
                aria-describedby={
                  error
                    ? "password-error"
                    : undefined
                }
              />

              {error && (
                <p
                  id="password-error"
                  className="error"
                >
                  {String(error)}
                </p>
              )}
            </div>
          );
        }}
      </form.Field>

      <form.Subscribe
        selector={(state) => [
          state.canSubmit,
          state.isSubmitting,
          state.isDirty,
        ]}
      >
        {([
          canSubmit,
          isSubmitting,
          isDirty,
        ]) => (
          <>
            <p>
              {isDirty
                ? "Unsaved changes"
                : "No changes"}
            </p>

            <button
              type="submit"
              disabled={
                !canSubmit ||
                isSubmitting
              }
            >
              {isSubmitting
                ? "Registering..."
                : "Register"}
            </button>
          </>
        )}
      </form.Subscribe>
    </form>
  );
}

TanStack Form supports field-level and form-level validation, multiple validation timings, and synchronous or asynchronous validation.

TanStack Form advantages

Strong type inference
Framework-agnostic core
Headless architecture
Fine-grained subscriptions
Controlled and predictable state
Flexible validation timing
Designed for composition and large applications
Useful when forms are central to the product

TanStack Form disadvantages

More concepts to learn
APIs can feel verbose for small forms
Controlled architecture still involves value-driven updates
A newer ecosystem than long-established alternatives
May be unnecessary for simple login or search forms

Form-library comparison

Library	Main architecture	Input style	Main strength	Main trade-off
Formik	Central React form state	Mostly controlled	Familiar, mature mental model	Can create broad rerenders and boilerplate
Final Form	Framework-independent subscription engine	Adapter-dependent	Fine-grained subscriptions	More architecture to understand
React Final Form	React wrapper over Final Form	Usually controlled through field props	Precise rerender subscriptions	Render-prop and subscription complexity
React Hook Form	Registration, refs, subscriptions	Uncontrolled-first	Low boilerplate and fewer React updates	Different mental model; controlled components need adapters
TanStack Form	Typed controlled form engine with subscriptions	Controlled	Type safety, composition, framework support	More concepts and verbosity

When did each approach become popular?

Rather than treating popularity as a single release date, it is better to think in ecosystem generations.

Early to mid-2010s
└── Hand-written controlled React forms

Late 2010s
├── Formik becomes a common default
└── Final Form / React Final Form introduce
    subscription-focused alternatives

React Hooks era, from 2019 onward
└── React Hook Form grows around hooks,
    registration, refs, and uncontrolled inputs

2020s
└── TypeScript-first and framework-agnostic
    systems such as TanStack Form expand
    the design space

Repository activity and official resources support Formik and React Final Form adoption beginning around 2017, while React Hook Form had an active public user base by 2019.

Popularity does not automatically determine the best choice for your project.

Which library should you choose?

Choose plain React state when:

The form has one to three fields
Validation is simple
There are no dynamic arrays
You do not need elaborate touched or dirty state
Adding a dependency would provide little value

Examples:

Search box
Newsletter subscription
Simple filter
Two-field login

Consider Formik when:

The team already uses Formik
Existing components are built around it
Developers understand its conventions
Migrating would provide little measurable benefit
Controlled state matches the product requirements

Do not rewrite stable forms merely because another library is newer.

Consider React Final Form when:

Fine-grained subscriptions are valuable
The team understands subscription-based state
Existing architecture uses Final Form
Form state must be managed independently of React
Precise control over updates matters

Consider React Hook Form when:

You want low boilerplate
Forms mostly use native inputs
Performance is important
You need Zod or another schema resolver
The project uses TypeScript
You need dynamic field arrays
You want clear server-error integration

Consider TanStack Form when:

Forms are central to the application
Type safety is a major priority
The project needs complex validation timing
Framework-independent architecture matters
The team values controlled predictability
The team accepts a larger learning investment

Common beginner mistake: choosing from benchmark charts alone

A form library may advertise fewer rerenders or smaller bundles.

Those factors matter, but they are not the complete decision.

Also evaluate:

Team knowledge
Documentation quality
Accessibility patterns
Validation integration
Design-system compatibility
Testing strategy
Migration cost
Long-term maintenance
Complex-field support
Server-error handling

The fastest library in a small artificial benchmark is not automatically the safest architectural choice for your production application.

Common beginner mistake: installing multiple form libraries

Avoid using:

Formik in one new form
React Hook Form in another
TanStack Form in another
Custom useState in every remaining form

without a clear reason.

This creates:

Inconsistent error handling
Different validation timing
Different reusable components
More dependencies
More onboarding difficulty
More testing patterns

A team should usually establish a default approach while allowing justified exceptions.

Common beginner mistake: expecting the library to provide security

Form libraries improve frontend behavior.

They do not replace:

Server-side validation
Authorization
Rate limiting
CSRF defenses where required
Secure cookies
Password hashing
Database constraints
File scanning
Output encoding

Even a perfectly validated React form can be bypassed by calling the API directly.

Senior engineer tip: separate concerns

A form usually contains at least four layers.

1. Presentation
   Labels, inputs, errors, layout

2. Form state
   Values, touched, dirty, submitting

3. Validation
   Required fields, formats, business rules

4. Data submission
   API requests, server errors, retries

Avoid combining everything in one component.

A healthier direction looks like:

RegistrationForm
├── registrationSchema
├── registerUser API function
├── reusable Input component
└── form-library integration

Later in this series, we will implement that structure using:

React Hook Form
+
Zod
+
TypeScript
+
Express backend

Interview questions

1. Why do React form libraries exist?

They reduce repeated code for:

Values
Errors
Touched state
Dirty state
Validation
Submission
Resetting
Dynamic fields
Nested data

They also provide consistent APIs and performance strategies.

2. What is the difference between Formik and React Hook Form?

Formik commonly follows a controlled, React-state-oriented model.

React Hook Form is uncontrolled-first and registers inputs using refs and event handlers, reducing the need to store every keystroke in parent React state.

3. What is the difference between Final Form and React Final Form?

Final Form is the framework-independent form-state engine.

React Final Form is the React integration built on top of Final Form.

4. What is a subscription-based form library?

A subscription-based library allows fields or components to listen only to specific parts of form state.

For example, an email error component may subscribe to:

email.error
email.touched

It does not need to update when the password value changes.

5. Should every React form use a library?

No.

A small form may be simpler with useState or native form APIs.

Use a library when it removes more complexity than it introduces.

Performance comparison

Manual controlled form

Email changes
     ↓
Parent state updates
     ↓
Parent component runs
     ↓
All child JSX is recalculated

Subscription-based form

Email changes
     ↓
Form store updates email
     ↓
Email subscribers are notified
     ↓
Only relevant consumers update

Uncontrolled-first form

Email changes
     ↓
Browser input stores value
     ↓
Form library observes/registers field
     ↓
React rerender happens only when
subscribed form state must change

These diagrams are simplified.

Real performance depends on:

Component boundaries
Subscriptions
Validation mode
Watched fields
Controlled third-party inputs
Parent rerenders
Derived calculations
Application size

Part 2 summary

We began with a manual form that scaled poorly.

DOM queries
Validation functions
Error elements
Event listeners
Loading flags
Nested data
Dynamic fields

Then React introduced declarative, state-driven UI.

User input
    ↓
Update React state
    ↓
Component runs
    ↓
UI is derived from state

Controlled forms gave us predictability, but large forms required us to manually manage:

values
errors
touched
dirtyFields
isDirty
isValid
isSubmitting
reset
validation

Form libraries emerged because teams were rebuilding the same infrastructure repeatedly.

Manual controlled forms
          ↓
Repeated state-management patterns
          ↓
Formik and Final Form generation
          ↓
Hooks and uncontrolled-first approaches
          ↓
Modern typed form engines

The major lesson is:

A form library does not remove form complexity. It organizes and abstracts that complexity.

In the next part, we will examine React Hook Form in detail.

We will cover:

Stage 9
React Hook Form philosophy and architecture

Stage 10
useForm, register, handleSubmit, watch,
setValue, getValues, reset, trigger,
Controller, formState, and more

Stage 11
Yup, Zod, Valibot, Vest, and manual validation

Stage 12
React Hook Form with Zod and TypeScript

The Evolution of Web Forms — Part 1

Karthik Reddy — Mon, 24 Aug 2026 06:32:00 +0000

The Evolution of Web Forms Part-1 — From Plain HTML to AJAX

Modern React forms can feel unnecessarily complicated when you first encounter tools such as React Hook Form, Zod, resolvers, controlled inputs, refs, formState, and server-error handling.

Why do we need all of that?

Why not simply read the value from an input and send it to the server?

To understand why modern form libraries exist, we need to understand the problems developers faced before those libraries were created.

In this series, we will evolve the same idea step by step:

Plain HTML
    ↓
Native HTML validation
    ↓
JavaScript validation
    ↓
AJAX submission
    ↓
React controlled forms
    ↓
Form libraries
    ↓
React Hook Form
    ↓
React Hook Form + Zod
    ↓
Production form architecture

This first part covers the first four stages:

Plain HTML forms
Native HTML validation
Vanilla JavaScript validation
AJAX form submission

By the end, you will understand how forms worked before React and why each new approach became necessary.

Stage 1: Plain HTML Forms

Before React, AJAX, or even large amounts of client-side JavaScript, browsers already knew how to submit forms.

HTML forms are not just visual containers. They are a built-in browser mechanism for collecting data and sending an HTTP request.

A basic registration form

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />

    <title>Registration Form</title>
  </head>

  <body>
    <h1>Create an account</h1>

    <form action="/register" method="POST">
      <div>
        <label for="username">Username</label>

        <input
          id="username"
          name="username"
          type="text"
        />
      </div>

      <div>
        <label for="email">Email</label>

        <input
          id="email"
          name="email"
          type="email"
        />
      </div>

      <div>
        <label for="password">Password</label>

        <input
          id="password"
          name="password"
          type="password"
        />
      </div>

      <button type="submit">Register</button>
    </form>
  </body>
</html>

There is no JavaScript in this example.

The browser handles the entire submission process.

Understanding the `<form>` element

The <form> element groups fields that belong to one submission.

<form action="/register" method="POST">
  <!-- Form fields -->
</form>

The two most important attributes are:

action
method

The `action` attribute

The action tells the browser where the form data should be sent.

<form action="/register">

In this example, the browser sends the request to:

/register

If the website is running at:

https://example.com

the complete request URL becomes:

https://example.com/register

The action may also contain a complete URL:

<form action="https://api.example.com/register">

The `method` attribute

The method tells the browser which HTTP method to use.

The two methods traditionally supported by HTML forms are:

GET
POST

GET form

<form action="/search" method="GET">
  <input name="query" />
  <button type="submit">Search</button>
</form>

If the user enters:

react forms

the browser navigates to something similar to:

/search?query=react+forms

The data becomes part of the URL.

GET is commonly used for:

Search forms
Filters
Pagination
Read-only operations
Shareable URLs

Sensitive information should not be sent through query parameters.

Never send passwords using a GET form.

POST form

<form action="/register" method="POST">

POST sends the data in the HTTP request body instead of placing it in the URL.

POST is commonly used for:

Registration
Login
Creating resources
Uploading files
Submitting private information

Using POST does not automatically encrypt the data. HTTPS is still required.

The importance of the `name` attribute

Consider this input:

<input
  id="email"
  name="email"
  type="email"
/>

The id identifies the input inside the HTML document.

The name identifies the field during form submission.

When the browser submits the form, it creates key-value pairs using the name attributes.

username=Karthik
email=karthik@example.com
password=secret123

Without a name, the browser usually does not include the input in the submitted form data.

For example:

<input id="email" type="email" />

This field can appear on the screen, but its value will not be submitted as part of the normal browser form request.

This distinction is important:

id      → identifies the HTML element
name    → identifies the submitted form field
value   → contains the user's input

Understanding `<label>`

<label for="email">Email</label>

<input
  id="email"
  name="email"
  type="email"
/>

The label's for value matches the input's id.

label for="email"
        ↓
input id="email"

This association provides two important benefits.

Mouse and touch usability

Clicking the label focuses the input.

Accessibility

Screen readers can identify the input as an email field with the label “Email.”

Avoid building forms using placeholder text as the only label.

Bad:

<input
  type="email"
  placeholder="Enter your email"
/>

Better:

<label for="email">Email</label>

<input
  id="email"
  name="email"
  type="email"
  placeholder="karthik@example.com"
/>

A placeholder is an example or hint. It should not replace a label.

Understanding the submit button

<button type="submit">Register</button>

A button with type="submit" tells the browser to submit its associated form.

Inside a form, a button may behave as a submit button even when its type is omitted.

<button>Register</button>

However, relying on the default can create accidental submissions.

It is better to be explicit:

<button type="submit">Register</button>

For buttons that should not submit the form, use:

<button type="button">Show password</button>

What happens after clicking Submit?

Suppose the user enters:

Username: karthik
Email: karthik@example.com
Password: secret123

Then the user clicks Register.

The browser performs approximately the following steps:

User clicks Submit
        ↓
Browser finds the surrounding form
        ↓
Browser collects successful form controls
        ↓
Browser uses each field's name as the key
        ↓
Browser encodes the values
        ↓
Browser sends an HTTP request to the form action
        ↓
Server processes the request
        ↓
Server sends an HTTP response
        ↓
Browser replaces the current page with the response

The request may look conceptually like this:

POST /register HTTP/1.1
Host: localhost:3000
Content-Type: application/x-www-form-urlencoded

username=karthik&email=karthik%40example.com&password=secret123

The default encoding is commonly:

application/x-www-form-urlencoded

This means form values are encoded into key-value pairs.

Why does the page refresh?

Traditional form submission is also a browser navigation.

The browser sends the request and expects the server to return the next page.

For example:

Registration page
      ↓ submit
POST /register
      ↓
Server creates the user
      ↓
Server returns HTML or redirects
      ↓
Browser displays the new page

The server might redirect the user:

HTTP/1.1 302 Found
Location: /login

The browser then requests /login and displays the login page.

This is sometimes called the traditional multi-page application model.

Each important interaction can result in a new page request.

Complete working example

Create the following structure:

plain-html-form/
├── public/
│   └── index.html
├── package.json
└── server.js

`public/index.html`

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />

    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />

    <title>Plain HTML Registration</title>

    <style>
      body {
        max-width: 500px;
        margin: 40px auto;
        padding: 0 16px;
        font-family: Arial, sans-serif;
      }

      form {
        display: flex;
        flex-direction: column;
        gap: 16px;
      }

      .field {
        display: flex;
        flex-direction: column;
        gap: 6px;
      }

      input {
        padding: 10px;
        font-size: 16px;
      }

      button {
        padding: 10px;
        cursor: pointer;
      }
    </style>
  </head>

  <body>
    <h1>Create an account</h1>

    <form action="/register" method="POST">
      <div class="field">
        <label for="username">Username</label>

        <input
          id="username"
          name="username"
          type="text"
        />
      </div>

      <div class="field">
        <label for="email">Email</label>

        <input
          id="email"
          name="email"
          type="email"
        />
      </div>

      <div class="field">
        <label for="password">Password</label>

        <input
          id="password"
          name="password"
          type="password"
        />
      </div>

      <button type="submit">Register</button>
    </form>
  </body>
</html>

`server.js`

const express = require("express");
const path = require("path");

const app = express();
const PORT = 3000;

// Reads application/x-www-form-urlencoded request bodies.
app.use(express.urlencoded({ extended: false }));

app.use(express.static(path.join(__dirname, "public")));

app.post("/register", (request, response) => {
  const { username, email, password } = request.body;

  console.log("Received registration data:", {
    username,
    email,
    password,
  });

  response.send(`
    <!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="UTF-8" />
        <title>Registration Successful</title>
      </head>

      <body>
        <h1>Registration successful</h1>
        <p>Welcome, ${username}.</p>
        <a href="/">Return to registration</a>
      </body>
    </html>
  `);
});

app.listen(PORT, () => {
  console.log(`Server running at http://localhost:${PORT}`);
});

Install and run

npm init -y
npm install express
node server.js

Open:

http://localhost:3000

After submission, notice that:

The browser sends a POST request.
The server receives the form fields.
The browser leaves the registration page.
The browser displays the HTML returned by the server.

Advantages of plain HTML forms

Work without JavaScript
Built directly into browsers
Simple to understand
Good accessibility when correctly structured
Can function on slow devices
Support keyboard submission
Easy for search engines and assistive technology to understand
Useful as a progressive-enhancement foundation

Disadvantages of plain HTML forms

The page navigates or refreshes after submission
There is little control over the user experience
Validation depends mainly on the server
Error messages often require rendering another page
Preserving entered values after a server error requires additional work
Loading states are difficult to display without JavaScript
Complex interactions are difficult to implement

Common beginner mistakes

Forgetting `name`

<input id="email" type="email" />

The field may not be included in the submitted request.

Using GET for passwords

<form method="GET">

This can expose the password in URLs, browser history, analytics, logs, and server records.

Using placeholders instead of labels

Placeholder text disappears when the user starts typing and is not a proper replacement for a visible label.

Forgetting the button type

A button intended to toggle password visibility may accidentally submit the form.

<button type="button">Show password</button>

Security note

A form is not secure merely because it uses method="POST".

Production forms should also consider:

HTTPS
Server-side validation
Password hashing
CSRF protection where applicable
Rate limiting
Input sanitization where appropriate
Secure cookies
Authentication and authorization
Protection against automated abuse

Never trust data only because it came from an HTML form.

Interview question

What is the difference between `id` and `name` in an input?

id identifies the HTML element and connects it to labels or accessibility attributes.

name determines the key used when the browser submits the form.

<input
  id="user-email"
  name="email"
/>

The server receives:

email=<entered-value>

It does not receive:

user-email=<entered-value>

Why this evolved

Plain HTML forms could submit data reliably, but users could enter completely invalid information. Developers needed a way to catch basic mistakes before sending the request to the server. This led to native HTML validation.

Stage 2: Native HTML Validation

Imagine a registration form where the user submits:

Username:
Email: hello
Password: 12

Without validation, the browser sends this data to the server.

The server then needs to reject it and return an error response.

This creates unnecessary work:

Invalid input
    ↓
Network request
    ↓
Server processing
    ↓
Error response
    ↓
Page rendered again

Browsers introduced validation attributes that allow developers to describe basic input rules directly in HTML.

The `required` attribute

<input
  id="username"
  name="username"
  type="text"
  required
/>

The browser prevents form submission when the field is empty.

<input required />

This is a boolean attribute. It does not need:

required="true"

Although that may work, the standard shorthand is simply:

required

`minlength` and `maxlength`

<input
  id="username"
  name="username"
  type="text"
  minlength="3"
  maxlength="20"
/>

This means the username should contain between 3 and 20 characters.

For passwords:

<input
  id="password"
  name="password"
  type="password"
  minlength="8"
  maxlength="72"
/>

maxlength can also prevent the user from entering more characters.

The `pattern` attribute

The pattern attribute applies a regular-expression rule.

<input
  id="username"
  name="username"
  type="text"
  pattern="[A-Za-z0-9_]+"
/>

This accepts:

karthik
karthik_2005
User123

It rejects values containing spaces or unsupported symbols.

A more complete example:

<input
  id="username"
  name="username"
  type="text"
  required
  minlength="3"
  maxlength="20"
  pattern="[A-Za-z0-9_]+"
  title="Use only letters, numbers, and underscores"
/>

The title provides additional guidance that some browsers may include in their validation message.

Do not use complicated regular expressions when a clearer validation strategy is available.

Email input

<input
  id="email"
  name="email"
  type="email"
  required
/>

The browser checks whether the value resembles an email address.

It may reject:

hello
karthik@
@example.com

However, this check is intentionally basic.

It cannot determine whether:

The domain exists
The mailbox exists
The user owns the email address
The email is already registered

Email verification and server-side uniqueness checks are still required.

Number input

<input
  id="age"
  name="age"
  type="number"
  min="18"
  max="100"
/>

This field accepts numeric input and applies minimum and maximum rules.

Minimum: 18
Maximum: 100

Do not assume type="number" is correct for every value containing digits.

Phone numbers, PIN codes, postal codes, Aadhaar-like identifiers, and credit-card numbers are identifiers, not mathematical quantities.

They may contain:

Leading zeroes
Spaces
Country prefixes
Formatting characters

Such values are often better represented using text inputs with appropriate input modes.

<input
  type="text"
  inputmode="numeric"
/>

Date input

<input
  id="birthDate"
  name="birthDate"
  type="date"
  required
/>

The browser may display a native date picker.

The interface can differ between:

Chrome
Firefox
Safari
Mobile browsers
Operating systems

The submitted value generally follows this shape:

YYYY-MM-DD

For example:

2005-08-24

URL input

<input
  id="portfolio"
  name="portfolio"
  type="url"
  placeholder="https://example.com"
/>

The browser checks whether the value resembles a URL.

Depending on the browser, entering:

example.com

may fail because the protocol is missing.

A complete value would be:

https://example.com

Password input

<input
  id="password"
  name="password"
  type="password"
  required
  minlength="8"
/>

type="password" hides the visible characters.

It does not:

Encrypt the password
Hash the password
Secure the network request
Protect the server database

HTTPS protects data in transit.

The server should hash passwords using an appropriate password-hashing algorithm before storage.

Complete native-validation example

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />

    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />

    <title>HTML Validated Registration</title>

    <style>
      body {
        max-width: 520px;
        margin: 40px auto;
        padding: 0 16px;
        font-family: Arial, sans-serif;
      }

      form {
        display: flex;
        flex-direction: column;
        gap: 16px;
      }

      .field {
        display: flex;
        flex-direction: column;
        gap: 6px;
      }

      input {
        padding: 10px;
        font-size: 16px;
      }

      input:invalid:not(:placeholder-shown) {
        border: 2px solid #b91c1c;
      }

      input:valid:not(:placeholder-shown) {
        border: 2px solid #15803d;
      }

      button {
        padding: 10px;
        cursor: pointer;
      }

      .hint {
        color: #555;
        font-size: 14px;
      }
    </style>
  </head>

  <body>
    <h1>Create an account</h1>

    <form action="/register" method="POST">
      <div class="field">
        <label for="username">Username</label>

        <input
          id="username"
          name="username"
          type="text"
          required
          minlength="3"
          maxlength="20"
          pattern="[A-Za-z0-9_]+"
          placeholder="karthik_2005"
          title="Use 3–20 letters, numbers, or underscores"
        />

        <span class="hint">
          Use 3–20 letters, numbers, or underscores.
        </span>
      </div>

      <div class="field">
        <label for="email">Email</label>

        <input
          id="email"
          name="email"
          type="email"
          required
          placeholder="karthik@example.com"
        />
      </div>

      <div class="field">
        <label for="age">Age</label>

        <input
          id="age"
          name="age"
          type="number"
          required
          min="18"
          max="100"
          placeholder="21"
        />
      </div>

      <div class="field">
        <label for="birthDate">Date of birth</label>

        <input
          id="birthDate"
          name="birthDate"
          type="date"
          required
        />
      </div>

      <div class="field">
        <label for="portfolio">Portfolio URL</label>

        <input
          id="portfolio"
          name="portfolio"
          type="url"
          placeholder="https://example.com"
        />
      </div>

      <div class="field">
        <label for="password">Password</label>

        <input
          id="password"
          name="password"
          type="password"
          required
          minlength="8"
          maxlength="72"
          placeholder="Minimum 8 characters"
        />
      </div>

      <button type="submit">Register</button>
    </form>
  </body>
</html>

What happens during native validation?

When the user submits the form:

User clicks Submit
        ↓
Browser checks built-in constraints
        ↓
Are all fields valid?
       / \
     No   Yes
     ↓     ↓
Show     Send HTTP
message  request

When a field is invalid, the browser:

Stops the form submission.
Focuses an invalid field.
Displays a browser-generated message.
Does not send the request.

The exact message depends on the browser and operating-system language.

Examples may resemble:

Please fill out this field.
Please include an “@” in the email address.
Please lengthen this text to 8 characters or more.

The browser Constraint Validation API

Native validation is not limited to HTML attributes.

JavaScript can inspect a field's validity:

const emailInput = document.getElementById("email");

console.log(emailInput.validity);
console.log(emailInput.validationMessage);
console.log(emailInput.checkValidity());

You can also assign a custom native validation message:

const usernameInput =
  document.getElementById("username");

usernameInput.setCustomValidity(
  "This username is not available."
);

To remove the custom error:

usernameInput.setCustomValidity("");

This API became an important bridge between built-in browser validation and fully custom JavaScript validation.

Advantages of native HTML validation

Requires little code
Works without JavaScript
Prevents many invalid requests
Integrates with browser focus behavior
Supports keyboard users
Provides semantic information to browsers
Useful for simple forms
Can serve as a fallback even when JavaScript exists

Disadvantages of native HTML validation

Error-message design differs between browsers
Styling browser validation messages is limited
Messages may be difficult to customize consistently
Cross-field validation is difficult
Asynchronous validation is not handled
Cannot check whether an email already exists
Cannot easily validate complex business rules
Some rules are too complicated for HTML attributes
Browser behavior can vary

A cross-field validation problem

Consider these fields:

<input
  id="password"
  name="password"
  type="password"
/>

<input
  id="confirmPassword"
  name="confirmPassword"
  type="password"
/>

HTML can validate the minimum length of each field.

However, HTML alone cannot easily express:

confirmPassword must equal password

That validation depends on comparing two fields.

Similarly, HTML cannot independently determine:

startDate must be before endDate

or:

at least one communication method must be selected

These requirements encouraged developers to add custom JavaScript.

Common beginner mistakes

Treating native email validation as complete verification

<input type="email" />

This only checks the general format. It does not prove that the email exists or belongs to the user.

Using a regular expression for every rule

Large expressions become difficult to read and maintain.

Validation should communicate business meaning, not merely demonstrate regex knowledge.

Relying only on frontend validation

Users can bypass browser validation using:

Browser developer tools
Direct API clients
Automated scripts
Modified JavaScript
Tools such as curl or Postman

The server must validate the request independently.

Using only color to show validity

A red or green border is not sufficient.

Users with visual impairments or color-vision differences may not understand the result.

Display text errors and use accessibility attributes.

Senior engineer tip

Use native HTML semantics even when you plan to use JavaScript, React, or React Hook Form.

Modern libraries should enhance correct HTML rather than replace it.

Good foundations still include:

<label for="email">Email</label>
<input id="email" name="email" type="email" />
<button type="submit">Submit</button>

Interview question

Why is frontend validation not enough?

Frontend validation improves user experience, but it cannot be trusted for security.

A client can modify or bypass frontend code. Therefore, the server must validate every request before using or storing its data.

Why this evolved

Native HTML validation handled simple rules, but production applications needed custom messages, cross-field validation, business rules, and dynamic UI behavior. Developers therefore moved validation logic into JavaScript.

Stage 3: Vanilla JavaScript Validation

JavaScript gave developers complete control over form behavior.

Instead of immediately allowing the browser to submit the form, JavaScript could:

Intercept submission
Read input values
Validate custom rules
Display custom errors
Remove old errors
Prevent invalid requests
Continue submission when data was valid

Intercepting form submission

const form = document.getElementById("register-form");

form.addEventListener("submit", function (event) {
  event.preventDefault();

  console.log("Form submission intercepted");
});

The important method is:

event.preventDefault();

A form's default behavior is to submit and navigate.

preventDefault() cancels that default browser action.

Without preventDefault()
Submit → browser request → page navigation

With preventDefault()
Submit → JavaScript receives control

At this point, JavaScript becomes responsible for deciding what happens next.

Selecting elements

`getElementById()`

const emailInput =
  document.getElementById("email");

This finds the element whose id is email.

<input id="email" />

`querySelector()`

const form =
  document.querySelector("#register-form");

querySelector() accepts a CSS selector.

Examples:

document.querySelector("#email");
document.querySelector(".error-message");
document.querySelector('input[name="email"]');
document.querySelector("form");

It returns the first matching element.

To select multiple elements:

const inputs = document.querySelectorAll("input");

Reading input values

const email = emailInput.value;

Suppose the user enters:

   karthik@example.com

The value includes the spaces.

Use trim() to remove whitespace from the beginning and end:

const email = emailInput.value.trim();

Now the value becomes:

karthik@example.com

Be careful when trimming passwords.

A password may intentionally contain leading or trailing spaces. Whether trimming is allowed should be a deliberate product rule.

Regular-expression validation

A regular expression can check whether text matches a pattern.

A practical, intentionally simple email check might be:

const emailPattern =
  /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

Then:

const isValidEmail =
  emailPattern.test(email);

This does not prove that the email exists. It only performs a basic structural check.

Avoid attempting to perfectly reproduce the complete email specification with an enormous frontend regex.

Showing field errors

A common structure is:

<div class="field">
  <label for="email">Email</label>

  <input
    id="email"
    name="email"
    type="email"
  />

  <p
    id="email-error"
    class="error"
  ></p>
</div>

JavaScript can update the error:

const emailError =
  document.getElementById("email-error");

emailError.textContent =
  "Please enter a valid email address.";

It can also mark the input as invalid:

emailInput.setAttribute(
  "aria-invalid",
  "true"
);

To remove the error:

emailError.textContent = "";

emailInput.setAttribute(
  "aria-invalid",
  "false"
);

Creating reusable error functions

Instead of repeating the same code, create helper functions.

function showError(input, errorElement, message) {
  input.setAttribute("aria-invalid", "true");
  errorElement.textContent = message;
}

function clearError(input, errorElement) {
  input.setAttribute("aria-invalid", "false");
  errorElement.textContent = "";
}

Usage:

showError(
  emailInput,
  emailError,
  "Please enter a valid email address."
);

Or:

clearError(emailInput, emailError);

This is an early example of abstraction.

Developers noticed repeated form operations and moved them into reusable functions.

The same motivation later produced reusable React components, custom hooks, and complete form libraries.

Complete JavaScript-validation example

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />

    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />

    <title>JavaScript Form Validation</title>

    <style>
      body {
        max-width: 520px;
        margin: 40px auto;
        padding: 0 16px;
        font-family: Arial, sans-serif;
      }

      form {
        display: flex;
        flex-direction: column;
        gap: 18px;
      }

      .field {
        display: flex;
        flex-direction: column;
        gap: 6px;
      }

      input {
        padding: 10px;
        border: 1px solid #777;
        border-radius: 4px;
        font-size: 16px;
      }

      input[aria-invalid="true"] {
        border: 2px solid #b91c1c;
      }

      .error {
        min-height: 20px;
        margin: 0;
        color: #b91c1c;
        font-size: 14px;
      }

      button {
        padding: 10px;
        cursor: pointer;
      }

      .success {
        color: #15803d;
      }
    </style>
  </head>

  <body>
    <h1>Create an account</h1>

    <form id="register-form" novalidate>
      <div class="field">
        <label for="username">Username</label>

        <input
          id="username"
          name="username"
          type="text"
          aria-describedby="username-error"
          aria-invalid="false"
        />

        <p
          id="username-error"
          class="error"
        ></p>
      </div>

      <div class="field">
        <label for="email">Email</label>

        <input
          id="email"
          name="email"
          type="email"
          aria-describedby="email-error"
          aria-invalid="false"
        />

        <p
          id="email-error"
          class="error"
        ></p>
      </div>

      <div class="field">
        <label for="password">Password</label>

        <input
          id="password"
          name="password"
          type="password"
          aria-describedby="password-error"
          aria-invalid="false"
        />

        <p
          id="password-error"
          class="error"
        ></p>
      </div>

      <button type="submit">Register</button>

      <p
        id="form-message"
        role="status"
      ></p>
    </form>

    <script>
      const form =
        document.getElementById("register-form");

      const usernameInput =
        document.getElementById("username");

      const emailInput =
        document.getElementById("email");

      const passwordInput =
        document.getElementById("password");

      const usernameError =
        document.getElementById("username-error");

      const emailError =
        document.getElementById("email-error");

      const passwordError =
        document.getElementById("password-error");

      const formMessage =
        document.getElementById("form-message");

      const usernamePattern = /^[A-Za-z0-9_]+$/;

      const emailPattern =
        /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

      function showError(
        input,
        errorElement,
        message
      ) {
        input.setAttribute(
          "aria-invalid",
          "true"
        );

        errorElement.textContent = message;
      }

      function clearError(
        input,
        errorElement
      ) {
        input.setAttribute(
          "aria-invalid",
          "false"
        );

        errorElement.textContent = "";
      }

      function clearAllErrors() {
        clearError(
          usernameInput,
          usernameError
        );

        clearError(
          emailInput,
          emailError
        );

        clearError(
          passwordInput,
          passwordError
        );

        formMessage.textContent = "";
        formMessage.className = "";
      }

      function validateUsername(username) {
        if (username.length === 0) {
          return "Username is required.";
        }

        if (username.length < 3) {
          return "Username must contain at least 3 characters.";
        }

        if (username.length > 20) {
          return "Username cannot exceed 20 characters.";
        }

        if (!usernamePattern.test(username)) {
          return "Use only letters, numbers, and underscores.";
        }

        return "";
      }

      function validateEmail(email) {
        if (email.length === 0) {
          return "Email is required.";
        }

        if (!emailPattern.test(email)) {
          return "Please enter a valid email address.";
        }

        return "";
      }

      function validatePassword(password) {
        if (password.length === 0) {
          return "Password is required.";
        }

        if (password.length < 8) {
          return "Password must contain at least 8 characters.";
        }

        if (!/[A-Z]/.test(password)) {
          return "Password must contain an uppercase letter.";
        }

        if (!/[a-z]/.test(password)) {
          return "Password must contain a lowercase letter.";
        }

        if (!/[0-9]/.test(password)) {
          return "Password must contain a number.";
        }

        return "";
      }

      form.addEventListener(
        "submit",
        function (event) {
          event.preventDefault();

          clearAllErrors();

          const username =
            usernameInput.value.trim();

          const email =
            emailInput.value.trim();

          // The password is not trimmed intentionally.
          const password =
            passwordInput.value;

          const usernameMessage =
            validateUsername(username);

          const emailMessage =
            validateEmail(email);

          const passwordMessage =
            validatePassword(password);

          let isValid = true;

          if (usernameMessage) {
            showError(
              usernameInput,
              usernameError,
              usernameMessage
            );

            isValid = false;
          }

          if (emailMessage) {
            showError(
              emailInput,
              emailError,
              emailMessage
            );

            isValid = false;
          }

          if (passwordMessage) {
            showError(
              passwordInput,
              passwordError,
              passwordMessage
            );

            isValid = false;
          }

          if (!isValid) {
            const firstInvalidInput =
              form.querySelector(
                '[aria-invalid="true"]'
              );

            firstInvalidInput?.focus();

            return;
          }

          const registrationData = {
            username,
            email,
            password,
          };

          console.log(
            "Valid registration data:",
            registrationData
          );

          formMessage.textContent =
            "Validation passed. The form is ready to be submitted.";

          formMessage.className = "success";
        }
      );

      usernameInput.addEventListener(
        "input",
        function () {
          clearError(
            usernameInput,
            usernameError
          );
        }
      );

      emailInput.addEventListener(
        "input",
        function () {
          clearError(
            emailInput,
            emailError
          );
        }
      );

      passwordInput.addEventListener(
        "input",
        function () {
          clearError(
            passwordInput,
            passwordError
          );
        }
      );
    </script>
  </body>
</html>

What does `novalidate` do?

The form contains:

<form id="register-form" novalidate>

novalidate disables the browser's default validation messages for that form.

This allows our JavaScript to display custom errors consistently.

Without novalidate, both systems could become involved:

Browser validation
+
Custom JavaScript validation

That can produce confusing or duplicated behavior.

Using novalidate does not mean the inputs should lose semantic attributes. You can still use meaningful types such as:

<input type="email" />

Mobile browsers may use that information to provide an appropriate keyboard.

JavaScript validation flow

User submits form
        ↓
submit event fires
        ↓
preventDefault()
        ↓
Read input values
        ↓
Normalize selected values
        ↓
Run validation functions
        ↓
Collect validation results
        ↓
Are there errors?
       / \
     Yes  No
      ↓    ↓
Display  Prepare data
errors   for submission
      ↓
Focus first invalid input

Why separate validation functions?

Instead of placing every condition inside the submit handler:

function validateEmail(email) {
  // Email rules
}

function validatePassword(password) {
  // Password rules
}

This provides:

Better readability
Easier testing
Reuse
Smaller functions
Separation of concerns
Easier rule changes

This pattern is an early version of schema validation.

Later, libraries such as Zod allow us to describe the same rules declaratively.

Instead of:

function validateUsername(username) {
  if (username.length === 0) {
    return "Username is required.";
  }

  if (username.length < 3) {
    return "Username is too short.";
  }

  return "";
}

we will eventually write something similar to:

const schema = z.object({
  username: z
    .string()
    .min(1, "Username is required")
    .min(3, "Username is too short"),
});

We are not skipping directly to Zod because understanding the manual version explains what Zod is replacing.

Advantages of JavaScript validation

Complete control over error messages
Custom UI design
Cross-field validation
Dynamic rules
Immediate feedback
Ability to focus invalid fields
Conditional validation
Better interaction than server-only validation
Can validate while typing, on blur, or on submit

Disadvantages of JavaScript validation

More code
More DOM queries
Repeated error-handling logic
Validation rules can become scattered
Event listeners become difficult to manage
Complex forms create large files
Manual state tracking becomes difficult
Client-side code can still be bypassed
Accessibility must be implemented carefully

Common beginner mistakes

Showing errors without clearing them

An old error may remain visible even after the user fixes the input.

Clear errors during an appropriate event:

emailInput.addEventListener("input", () => {
  clearError(emailInput, emailError);
});

For some forms, clearing immediately may be misleading. Another strategy is to revalidate the field and clear the error only when it becomes valid.

Using only one global error

<p id="error">Something is wrong.</p>

This does not tell the user which field needs correction.

Field-level errors are usually clearer.

Validating on every keystroke too aggressively

Suppose the user starts typing:

Immediately displaying five errors can feel hostile.

A common strategy is:

First submission → show errors
Afterward → revalidate affected fields as the user edits

Form libraries later formalized these strategies using validation modes.

Forgetting accessibility attributes

An error visually displayed under an input may not automatically be understood by a screen reader.

Connect the input and error:

<input
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
/>

<p id="email-error">
  Please enter a valid email.
</p>

Trusting JavaScript validation on the backend

Frontend validation exists for user experience.

Backend validation exists for correctness and security.

Both are required.

Senior engineer tip: validation timing matters

Validation can happen at several moments.

Timing	Description	Benefit	Risk
On submit	Validate after submission	Least distracting	Feedback arrives later
On blur	Validate after leaving a field	Balanced feedback	User may miss the message
On change	Validate after every change	Fast feedback	Can be noisy
After first submit	Submit first, then revalidate while editing	Good production balance	More state to manage

Later, React Hook Form will expose these strategies through options such as:

mode: "onSubmit"
mode: "onBlur"
mode: "onChange"
mode: "onTouched"
mode: "all"

Interview question

What does `event.preventDefault()` do during form submission?

It prevents the browser's default form-submission behavior, which would normally send the request and navigate or refresh the page.

It allows JavaScript to validate or submit the data manually.

Why this evolved

JavaScript gave developers control over validation, but traditional submission still caused page navigation. Modern applications needed to send data, show loading indicators, handle errors, and update the interface without replacing the entire page. This led to AJAX forms.

Stage 4: AJAX Forms

AJAX stands for:

Asynchronous JavaScript and XML

Despite the name, modern AJAX applications commonly exchange JSON rather than XML.

The important idea is asynchronous communication.

JavaScript sends an HTTP request in the background while the current page remains open.

Traditional form versus AJAX form

Traditional submission

User submits
      ↓
Browser sends request
      ↓
Current page is left
      ↓
Server returns another document
      ↓
Browser renders the new page

AJAX submission

User submits
      ↓
JavaScript sends request
      ↓
Current page remains visible
      ↓
Server returns data
      ↓
JavaScript updates part of the page

This made applications feel faster and more interactive.

Why page refreshes became a problem

A complete page navigation can:

Lose temporary interface state
Reset scroll position
Interrupt animations or media
Make loading feel slower
Require the server to return complete HTML
Make small interactions feel heavy
Provide limited control over loading and error states

Consider a registration request that takes two seconds.

With a traditional form, the browser may show only a loading indicator in the tab.

With JavaScript, the application can display:

Creating your account...

It can also disable the button to prevent duplicate submissions.

Three common AJAX approaches

Historically, developers used several APIs and libraries.

XMLHttpRequest

XMLHttpRequest was the browser API commonly used for early AJAX applications.

const request = new XMLHttpRequest();

request.open(
  "POST",
  "/api/register"
);

request.setRequestHeader(
  "Content-Type",
  "application/json"
);

request.onload = function () {
  console.log(request.responseText);
};

request.onerror = function () {
  console.error("Network error");
};

request.send(
  JSON.stringify({
    email: "karthik@example.com",
  })
);

It works, but its event-based API can become verbose.

Fetch API

The Fetch API provides a promise-based interface.

const response = await fetch(
  "/api/register",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      email: "karthik@example.com",
    }),
  }
);

Then parse the JSON response:

const data = await response.json();

One important detail is that Fetch does not reject its promise merely because the server returns a status such as 400 or 500.

You should check:

if (!response.ok) {
  // Handle HTTP error
}

Axios

Axios is a third-party HTTP client.

const response = await axios.post(
  "/api/register",
  {
    email: "karthik@example.com",
  }
);

Axios commonly provides conveniences such as:

Automatic JSON transformation
Request and response interceptors
Configurable instances
Familiar error handling
Timeout configuration
Browser and Node.js support

However, it adds a dependency.

For many browser requests, Fetch is sufficient. Axios can still be useful when a project benefits from its abstractions.

Comparing XMLHttpRequest, Fetch, and Axios

Feature	XMLHttpRequest	Fetch	Axios
Built into browser	Yes	Yes	No
Promise-based by default	No	Yes	Yes
JSON parsing	Manual	Manual	Usually automatic
Rejects on 4xx/5xx	Manual handling	No	Yes
Interceptors	No built-in high-level API	Not directly	Yes
Modern readability	Lower	High	High
Extra dependency	No	No	Yes

The states of an AJAX form

An AJAX form is not simply “submitted” or “not submitted.”

It usually has several states.

Idle
 ↓
Validating
 ↓
Submitting
 ├──→ Success
 └──→ Error

At minimum, production forms usually need:

Idle state
Loading state
Success state
Error state

Loading state

While a request is running:

submitButton.disabled = true;
submitButton.textContent = "Creating account...";

After the request finishes:

submitButton.disabled = false;
submitButton.textContent = "Register";

Disabling the button reduces accidental duplicate requests.

However, the backend should still protect itself against duplicated operations when necessary. Client-side disabling is not a complete consistency guarantee.

Success state

When registration succeeds, the UI may:

Display a success message
Reset the form
Redirect to login
Display an email-verification instruction
Update application state

Example:

message.textContent =
  "Registration successful. Check your email.";

form.reset();

Error state

Errors can come from different sources.

Validation error

The email format is invalid.

Business-rule error

Email already exists.

Authentication or authorization error

Your session has expired.

Server error

Something went wrong on the server.

Network error

The device is offline or the server cannot be reached.

A good form should not display all these situations as:

Something went wrong.

Users need actionable information when it is safe to provide it.

Complete AJAX registration example

Create this structure:

ajax-registration/
├── public/
│   └── index.html
├── package.json
└── server.js

`public/index.html`

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />

    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0"
    />

    <title>AJAX Registration Form</title>

    <style>
      body {
        max-width: 520px;
        margin: 40px auto;
        padding: 0 16px;
        font-family: Arial, sans-serif;
      }

      form {
        display: flex;
        flex-direction: column;
        gap: 18px;
      }

      .field {
        display: flex;
        flex-direction: column;
        gap: 6px;
      }

      input {
        padding: 10px;
        border: 1px solid #777;
        border-radius: 4px;
        font-size: 16px;
      }

      input[aria-invalid="true"] {
        border: 2px solid #b91c1c;
      }

      .error {
        min-height: 20px;
        margin: 0;
        color: #b91c1c;
        font-size: 14px;
      }

      button {
        padding: 10px;
        cursor: pointer;
      }

      button:disabled {
        cursor: not-allowed;
        opacity: 0.7;
      }

      .success {
        color: #15803d;
      }

      .failure {
        color: #b91c1c;
      }
    </style>
  </head>

  <body>
    <h1>Create an account</h1>

    <form id="register-form" novalidate>
      <div class="field">
        <label for="username">Username</label>

        <input
          id="username"
          name="username"
          type="text"
          autocomplete="username"
          aria-describedby="username-error"
          aria-invalid="false"
        />

        <p
          id="username-error"
          class="error"
        ></p>
      </div>

      <div class="field">
        <label for="email">Email</label>

        <input
          id="email"
          name="email"
          type="email"
          autocomplete="email"
          aria-describedby="email-error"
          aria-invalid="false"
        />

        <p
          id="email-error"
          class="error"
        ></p>
      </div>

      <div class="field">
        <label for="password">Password</label>

        <input
          id="password"
          name="password"
          type="password"
          autocomplete="new-password"
          aria-describedby="password-error"
          aria-invalid="false"
        />

        <p
          id="password-error"
          class="error"
        ></p>
      </div>

      <button
        id="submit-button"
        type="submit"
      >
        Register
      </button>

      <p
        id="form-message"
        role="status"
        aria-live="polite"
      ></p>
    </form>

    <script>
      const form =
        document.getElementById("register-form");

      const submitButton =
        document.getElementById("submit-button");

      const formMessage =
        document.getElementById("form-message");

      const fields = {
        username: {
          input:
            document.getElementById("username"),

          error:
            document.getElementById(
              "username-error"
            ),
        },

        email: {
          input:
            document.getElementById("email"),

          error:
            document.getElementById(
              "email-error"
            ),
        },

        password: {
          input:
            document.getElementById("password"),

          error:
            document.getElementById(
              "password-error"
            ),
        },
      };

      const usernamePattern = /^[A-Za-z0-9_]+$/;

      const emailPattern =
        /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

      function showFieldError(
        fieldName,
        message
      ) {
        const field = fields[fieldName];

        if (!field) {
          return;
        }

        field.input.setAttribute(
          "aria-invalid",
          "true"
        );

        field.error.textContent = message;
      }

      function clearFieldError(fieldName) {
        const field = fields[fieldName];

        if (!field) {
          return;
        }

        field.input.setAttribute(
          "aria-invalid",
          "false"
        );

        field.error.textContent = "";
      }

      function clearAllErrors() {
        Object.keys(fields).forEach(
          clearFieldError
        );

        formMessage.textContent = "";
        formMessage.className = "";
      }

      function validateForm(data) {
        const errors = {};

        if (!data.username) {
          errors.username =
            "Username is required.";
        } else if (data.username.length < 3) {
          errors.username =
            "Username must contain at least 3 characters.";
        } else if (
          !usernamePattern.test(data.username)
        ) {
          errors.username =
            "Use only letters, numbers, and underscores.";
        }

        if (!data.email) {
          errors.email = "Email is required.";
        } else if (
          !emailPattern.test(data.email)
        ) {
          errors.email =
            "Please enter a valid email address.";
        }

        if (!data.password) {
          errors.password =
            "Password is required.";
        } else if (data.password.length < 8) {
          errors.password =
            "Password must contain at least 8 characters.";
        }

        return errors;
      }

      function setSubmitting(isSubmitting) {
        submitButton.disabled = isSubmitting;

        submitButton.textContent = isSubmitting
          ? "Creating account..."
          : "Register";

        fields.username.input.disabled =
          isSubmitting;

        fields.email.input.disabled =
          isSubmitting;

        fields.password.input.disabled =
          isSubmitting;
      }

      function focusFirstError(errors) {
        const firstFieldName =
          Object.keys(errors)[0];

        if (!firstFieldName) {
          return;
        }

        fields[firstFieldName]?.input.focus();
      }

      async function registerUser(data) {
        const response = await fetch(
          "/api/register",
          {
            method: "POST",

            headers: {
              "Content-Type":
                "application/json",
            },

            body: JSON.stringify(data),
          }
        );

        let responseData;

        try {
          responseData = await response.json();
        } catch {
          responseData = {
            success: false,
            message:
              "The server returned an invalid response.",
          };
        }

        if (!response.ok) {
          const error = new Error(
            responseData.message ||
              "Registration failed."
          );

          error.status = response.status;
          error.data = responseData;

          throw error;
        }

        return responseData;
      }

      form.addEventListener(
        "submit",
        async function (event) {
          event.preventDefault();

          clearAllErrors();

          const formData = {
            username:
              fields.username.input.value.trim(),

            email:
              fields.email.input.value.trim(),

            password:
              fields.password.input.value,
          };

          const validationErrors =
            validateForm(formData);

          if (
            Object.keys(validationErrors).length >
            0
          ) {
            Object.entries(
              validationErrors
            ).forEach(
              ([fieldName, message]) => {
                showFieldError(
                  fieldName,
                  message
                );
              }
            );

            focusFirstError(validationErrors);

            return;
          }

          setSubmitting(true);

          formMessage.textContent =
            "Submitting your registration...";

          try {
            const result =
              await registerUser(formData);

            formMessage.textContent =
              result.message;

            formMessage.className = "success";

            form.reset();

            Object.keys(fields).forEach(
              clearFieldError
            );
          } catch (error) {
            console.error(
              "Registration error:",
              error
            );

            const backendError = error.data;

            if (
              backendError?.field &&
              fields[backendError.field]
            ) {
              showFieldError(
                backendError.field,
                backendError.message
              );

              fields[
                backendError.field
              ].input.focus();

              formMessage.textContent =
                "Please correct the highlighted field.";

              formMessage.className =
                "failure";
            } else {
              formMessage.textContent =
                error.message ||
                "Unable to create your account.";

              formMessage.className =
                "failure";
            }
          } finally {
            setSubmitting(false);
          }
        }
      );

      Object.keys(fields).forEach(
        (fieldName) => {
          fields[
            fieldName
          ].input.addEventListener(
            "input",
            function () {
              clearFieldError(fieldName);
            }
          );
        }
      );
    </script>
  </body>
</html>

`server.js`

const express = require("express");
const path = require("path");

const app = express();
const PORT = 3000;

app.use(express.json());

app.use(
  express.static(
    path.join(__dirname, "public")
  )
);

// A temporary in-memory list for demonstration.
// A production application would use a database.
const users = [
  {
    id: 1,
    username: "existing_user",
    email: "existing@example.com",
  },
];

function isNonEmptyString(value) {
  return (
    typeof value === "string" &&
    value.trim().length > 0
  );
}

app.post(
  "/api/register",
  async (request, response) => {
    const {
      username,
      email,
      password,
    } = request.body;

    // Server-side validation is still required.
    if (!isNonEmptyString(username)) {
      return response.status(400).json({
        success: false,
        field: "username",
        message: "Username is required.",
      });
    }

    if (!isNonEmptyString(email)) {
      return response.status(400).json({
        success: false,
        field: "email",
        message: "Email is required.",
      });
    }

    if (
      typeof password !== "string" ||
      password.length < 8
    ) {
      return response.status(400).json({
        success: false,
        field: "password",
        message:
          "Password must contain at least 8 characters.",
      });
    }

    const normalizedEmail =
      email.trim().toLowerCase();

    const normalizedUsername =
      username.trim();

    const emailAlreadyExists =
      users.some(
        (user) =>
          user.email.toLowerCase() ===
          normalizedEmail
      );

    if (emailAlreadyExists) {
      return response.status(409).json({
        success: false,
        field: "email",
        message:
          "An account with this email already exists.",
      });
    }

    const usernameAlreadyExists =
      users.some(
        (user) =>
          user.username.toLowerCase() ===
          normalizedUsername.toLowerCase()
      );

    if (usernameAlreadyExists) {
      return response.status(409).json({
        success: false,
        field: "username",
        message:
          "This username is already taken.",
      });
    }

    // Simulate database or email-service work.
    await new Promise((resolve) => {
      setTimeout(resolve, 1000);
    });

    const newUser = {
      id: users.length + 1,
      username: normalizedUsername,
      email: normalizedEmail,
    };

    users.push(newUser);

    return response.status(201).json({
      success: true,
      message:
        "Registration successful. Check your email to verify your account.",
      data: {
        user: newUser,
      },
    });
  }
);

app.use(
  (
    error,
    request,
    response,
    next
  ) => {
    console.error(error);

    response.status(500).json({
      success: false,
      message:
        "An unexpected server error occurred.",
    });
  }
);

app.listen(PORT, () => {
  console.log(
    `Server running at http://localhost:${PORT}`
  );
});

Install and run

npm init -y
npm install express
node server.js

Open:

http://localhost:3000

Test the following email:

existing@example.com

The backend returns:

{
  "success": false,
  "field": "email",
  "message": "An account with this email already exists."
}

The frontend reads:

backendError.field

which contains:

email

It then executes:

showFieldError(
  backendError.field,
  backendError.message
);

That becomes:

showFieldError(
  "email",
  "An account with this email already exists."
);

The helper looks up:

fields["email"]

which points to:

{
  input: emailInput,
  error: emailErrorElement
}

Therefore, only the email error is updated.

This is an important idea.

The backend error contains the field name:

{
  "field": "email"
}

The frontend uses that field name as a key:

fields[backendError.field]

Later, React Hook Form will do something conceptually similar:

setError("email", {
  type: "server",
  message: "Email already exists",
});

and expose the result through:

errors.email

Complete AJAX request lifecycle

User enters registration information
                ↓
User clicks Register
                ↓
submit event fires
                ↓
preventDefault()
                ↓
Frontend reads input values
                ↓
Frontend validates values
                ↓
Are there client errors?
          /             \
        Yes              No
         ↓                ↓
Show field errors     Set loading state
                          ↓
                   Send Fetch request
                          ↓
                     Express API
                          ↓
                 Server validates again
                          ↓
              Check database/business rules
                    /              \
                Failure           Success
                   ↓                 ↓
          Return error JSON    Create user
                   ↓                 ↓
         Frontend reads error  Return success JSON
                   ↓                 ↓
        Show field/global      Show success message
        error
                    \              /
                     ↓            ↓
                    Stop loading state

Understanding `try`, `catch`, and `finally`

try {
  const result = await registerUser(data);

  // Success
} catch (error) {
  // Failure
} finally {
  // Always runs
}

`try`

Contains the operation that may fail.

const result =
  await registerUser(formData);

`catch`

Runs when the request, parsing, or manually thrown HTTP error fails.

catch (error) {
  console.error(error);
}

`finally`

Runs after success or failure.

finally {
  setSubmitting(false);
}

This makes finally an appropriate place to restore the button and input states.

Without it, developers often forget to remove the loading state in one error path.

Why check `response.ok`?

Fetch treats a completed HTTP exchange as a fulfilled promise even when the server returns an error status.

For example:

HTTP/1.1 409 Conflict

The network request completed successfully from Fetch's perspective.

Therefore:

const response = await fetch(...);

if (!response.ok) {
  throw new Error("Request failed");
}

response.ok is generally true for successful 2xx responses.

Why validate on both frontend and backend?

The frontend checks:

if (!emailPattern.test(email)) {
  // Show error
}

The backend also validates:

if (!isNonEmptyString(email)) {
  return response.status(400).json(...);
}

This is intentional duplication at different trust boundaries.

Frontend validation
Purpose: user experience

Backend validation
Purpose: correctness and security

The backend cannot assume the request came from the official frontend.

An attacker or another client can call the API directly:

curl \
  -X POST \
  http://localhost:3000/api/register \
  -H "Content-Type: application/json" \
  -d '{}'

The server must protect itself.

Accessibility in the AJAX example

`aria-invalid`

<input aria-invalid="true" />

This tells assistive technology that the current field value is invalid.

When the field is valid or has not been marked invalid:

<input aria-invalid="false" />

`aria-describedby`

<input
  id="email"
  aria-describedby="email-error"
/>

<p id="email-error">
  Email already exists.
</p>

This creates an association:

Input's aria-describedby
            ↓
Element with matching id

A screen reader can announce the associated description or error.

`role="status"` and `aria-live`

<p
  id="form-message"
  role="status"
  aria-live="polite"
></p>

When JavaScript changes the text, assistive technology may announce it without forcing the user to move focus.

Examples:

Submitting your registration...
Registration successful.
Please correct the highlighted field.

Focus management

After validation fails:

firstInvalidInput?.focus();

After a backend field error:

fields[backendError.field].input.focus();

This helps keyboard and screen-reader users reach the field that requires attention.

Do not move focus unpredictably after every keystroke. Focus management should help the user, not fight them.

Advantages of AJAX forms

No complete page refresh
Better loading feedback
Fine-grained success and error states
Easier field-level backend errors
Can preserve unsent form data
Better experience for interactive applications
Allows partial page updates
Easier integration with JSON APIs
Enables single-page application behavior

Disadvantages of AJAX forms

More JavaScript
More UI states to manage
More error paths
Loading-state bugs
Duplicate-submission risks
Accessibility requires deliberate work
Network and server errors must be distinguished
Validation logic can become duplicated
Manual DOM management becomes difficult
Large forms create substantial complexity

The complexity is starting to grow

Our form now manages:

Input values
Validation rules
Field errors
Global errors
Loading state
Success state
Disabled state
Focus management
Request construction
Response parsing
Backend field errors
Network failures
Form reset
Accessibility attributes

And this is only a three-field form.

Imagine a production onboarding form with:

First name
Last name
Username
Email
Phone number
Password
Confirm password
Country
State
City
Postal code
Date of birth
Preferred language
Terms acceptance
Marketing preferences
Profile image
Resume upload
Multiple work experiences
Multiple education records

The JavaScript would need to track all those fields and their related states.

This is the beginning of the scaling problem.

Common beginner mistakes

Not disabling submission during a request

A user may click the button several times and create multiple requests.

submitButton.disabled = true;

The backend should still be designed safely because users can bypass the frontend.

Clearing the form before the request succeeds

Bad:

form.reset();

await registerUser(data);

If the request fails, the user loses everything they entered.

Better:

const result = await registerUser(data);

form.reset();

Reset only after confirmed success, unless the product deliberately requires another behavior.

Treating every error as a network error

A 409 Conflict response is different from a lost internet connection.

409 Conflict
→ Server responded
→ Email already exists

Network failure
→ Server may not have been reached

These should usually produce different messages.

Forgetting to handle non-JSON responses

The server, proxy, or hosting provider might return HTML or an empty body.

Wrapping JSON parsing can prevent another confusing error:

let data;

try {
  data = await response.json();
} catch {
  data = {
    message: "Invalid server response.",
  };
}

Exposing sensitive server information

Do not return internal stack traces, database queries, or infrastructure details to users.

Bad production response:

{
  "message": "Prisma error P2002 at /app/src/repository/user.ts:82"
}

Better public response:

{
  "success": false,
  "field": "email",
  "message": "An account with this email already exists."
}

Log the detailed internal error securely on the server.

Senior engineer tip: model form state explicitly

Even in Vanilla JavaScript, start thinking of the form as a state machine.

IDLE
  ↓
VALIDATING
  ↓
SUBMITTING
  ↓
SUCCESS or ERROR

Invalid combinations should be avoided.

For example, a form should not normally be:

isSubmitting = true
isSuccess = true

at the same time.

React will later make UI state more explicit, but React does not automatically solve state-design problems. It only gives us better tools for expressing them.

Performance note

In a small Vanilla JavaScript form, updating one error element is efficient:

emailError.textContent =
  "Email already exists.";

Only that DOM node changes.

When React entered the ecosystem, many forms were implemented using controlled inputs. Every keystroke updated React state and caused the component function to run again.

That created a new trade-off:

Manual DOM management
        versus
Declarative state-driven UI

React improved maintainability and predictability, but large controlled forms could produce boilerplate and unnecessary renders.

That problem eventually became one of the reasons React Hook Form gained popularity.

Interview questions

1. What is AJAX?

AJAX is a technique for sending and receiving data asynchronously using JavaScript without requiring a complete page navigation.

Modern AJAX applications commonly use JSON with Fetch or an HTTP library.

2. Does Fetch throw automatically for a 404 or 500 response?

No.

Fetch usually resolves when an HTTP response is received, even if the status is an error.

Check:

if (!response.ok) {
  // Handle HTTP error
}

3. What is the purpose of a loading state?

A loading state tells the user that the request is in progress and helps prevent repeated submissions.

It can also disable fields or buttons while the operation is running.

4. Why should backend errors have a consistent shape?

A consistent error structure allows the frontend to handle errors predictably.

For example:

{
  "success": false,
  "field": "email",
  "message": "Email already exists"
}

The frontend can map field to the corresponding input and display message beside it.

5. What is the difference between a network error and an HTTP error?

A network error means the request could not be completed normally, possibly because the user is offline, the server is unavailable, or the connection failed.

An HTTP error means the server returned a response with an error status such as 400, 401, 404, 409, or 500.

Why this evolved

AJAX improved the user experience, but manual DOM queries, validation functions, loading flags, error elements, and event listeners became difficult to maintain as forms grew. Applications needed a better way to connect UI with changing state. This created the conditions for React forms and controlled components.

Part 1 summary

We began with the browser doing almost everything:

HTML form
    ↓
Browser collects values
    ↓
Browser submits request
    ↓
Browser loads another page

Then we added browser validation:

HTML attributes
    ↓
Browser checks simple constraints
    ↓
Invalid submissions are stopped

Then we added JavaScript:

Intercept submission
    ↓
Read values
    ↓
Apply custom rules
    ↓
Display custom errors

Finally, we introduced AJAX:

Validate
    ↓
Set loading state
    ↓
Send background request
    ↓
Handle success or failure
    ↓
Update only the required UI

Each evolution solved a real problem.

However, each evolution also introduced new complexity.

Stage	Main improvement	New challenge
Plain HTML	Built-in form submission	Page navigation and limited validation
HTML validation	Basic client-side constraints	Limited customization and business rules
JavaScript validation	Custom logic and errors	Manual DOM and state management
AJAX forms	Submission without page refresh	Loading, errors, requests, and state complexity

The three-field AJAX example already contains substantial code.

The next stage will introduce React and ask an important question:

What if the interface were produced from state instead of manually changing DOM elements?

That leads us to:

Stage 5: Scaling problems
Stage 6: React controlled forms
Stage 7: Large React forms
Stage 8: The rise of form libraries

DEV Community: Karthik Reddy

The Evolution of Web Forms — Final Part

The Evolution of Web Forms — Final Part: Enterprise Architecture and the Future of Forms

Stage 17: Enterprise Forms

17.1 Multi-Step and Wizard Forms

The problem

Multi-step state model

Complete multi-step React Hook Form example

Why use FormProvider?

Validate only the current step

Advantages of multi-step forms

Disadvantages

Senior engineer tip

17.2 Conditional Fields

The problem

Complete conditional-field example

shouldUnregister decision

Advantages

Disadvantages

17.3 Dynamic Arrays with useFieldArray

The problem

Complete work-experience example

Why use field.id as the React key?

Dynamic error paths

Advantages

Disadvantages

Senior engineer tip

17.4 Nested Objects

Complete nested-object example

17.5 File Uploads

The problem

Complete resume-upload example

Do not manually set multipart content type

Server validation is mandatory

17.6 Drag-and-Drop Uploads

Complete drop-zone example

17.7 Debounced Validation

Complete debounced username check

Race-condition protection

Never rely on availability checks as a guarantee

17.8 Autosave and Draft Saving

The autosave state machine

Local draft example

Security warning

Server-side autosave hook

Autosave design questions

17.9 Optimistic UI

Complete optimistic skill example

When optimistic UI is appropriate

Enterprise Form Advantages

Enterprise Form Disadvantages

Why this evolved

Stage 18: Modern Production Form Architecture

Recommended feature structure

Responsibility boundaries

Schema

Form component

API function

Error mapper

Reusable field component

Page or route

18.1 Reusable FormField

What this component should handle

What it should not handle

18.2 Reusable Form Error

18.3 Schema Organization

18.4 API Layer

18.5 Loading States

18.6 Toast Notifications

Simple toast state example

18.7 Error Boundaries

Complete class error boundary

18.8 Form Error Mapping

18.9 Form Analytics

18.10 Testing Strategy

Schema test example

Component test example

Modern Form Architecture Diagram

Advantages of Modern Architecture

Disadvantages

Why use `FormProvider`?

`shouldUnregister` decision

17.3 Dynamic Arrays with `useFieldArray`

Why use `field.id` as the React key?

18.1 Reusable `FormField`

`useFormStatus`

`useActionState`

Why use `safeParse()` on the server?

`src/schemas/auth.schemas.ts`

`src/errors/ApiError.ts`

`src/middleware/validate.ts`

`src/services/auth.service.ts`