State

State is a value a component remembers between renders and can change. A filter term the user typed, whether a panel is open, which employee is selected.

The reason it needs a special mechanism is that a component is a function. Local variables inside a function are gone when it returns, and reassigning one would not tell React that anything had changed. useState gives you a value that survives across renders, plus a function that changes it and asks React to render again.

In a Next.js application, a component that holds state needs a "use client" line at the top of its file. Take that as given for now — the Server and Client Components lesson explains what it means and why the default is the other way round.

"use client";

import { useState } from "react";

export function EmployeeDirectory({ employees }: { employees: Employee[] }) {
  const [searchTerm, setSearchTerm] = useState("");

  // Derived during render. Not state.
  const matches = employees.filter((employee) =>
    employee.name.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <div>
      <label htmlFor="employee-search">Search by name</label>
      <input
        id="employee-search"
        value={searchTerm}
        onChange={(event) => setSearchTerm(event.target.value)}
      />
      <p className="text-sm text-slate-600">
        {matches.length} of {employees.length} employees
      </p>
      <EmployeeTable employees={matches} />
    </div>
  );
}

• useState returns a pair: the current value and a function that sets it. The array destructuring on the left is why you see two names in square brackets. The argument is the starting value, used on the first render only.
• Typing into the input calls setSearchTerm. React stores the new value and renders the component again. On that render, searchTerm is the new string.
• matches is computed from employees and searchTerm every render. It is not state, and putting it in state would create a second thing to keep in step with the first.
• The count paragraph reads matches.length. Nobody updates that number when the search changes — it is recalculated because the whole component runs again. That is the shift in thinking: you describe the screen for the current state instead of updating parts of it.
• The label is tied to the input with htmlFor and id. Without that, a screen reader announces an unlabelled text box, and clicking the label does not focus the field.

const [pageSize, setPageSize] = useState(10);

// Broken. Both calls read the same pageSize from this render, which is 10.
// Both therefore set it to 11, and the second overwrites the first.
function showTwoMore() {
  setPageSize(pageSize + 1);
  setPageSize(pageSize + 1);
}

// Correct. Each updater receives the value React has pending,
// so they apply one after the other and the result is 12.
function showTwoMoreCorrectly() {
  setPageSize((current) => current + 1);
  setPageSize((current) => current + 1);
}

• Calling the setter does not change the variable you are holding. pageSize is a value captured for this render, and it keeps that value until the next render replaces it. Reading it straight after setting it gives you the old number — this catches nearly everyone once.
• React also batches updates. Several setter calls from the same event are collected and applied together, then the component renders once. That is why the first version loses an update instead of rendering twice.
• The updater form — a function passed to the setter — is called by React with the latest pending value. Use it whenever the new value depends on the old one: counters, toggles, adding to a list, anything cumulative.
• When the new value is independent of the old, setSearchTerm(event.target.value) is direct and clear. There is no need to reach for an updater to satisfy a rule.

const [filters, setFilters] = useState({ department: "all", includeLeavers: false });
const [selectedIds, setSelectedIds] = useState<string[]>([]);

// Wrong: changes the existing object. React compares by reference,
// sees the same object, and may render nothing at all.
function chooseDepartmentWrongly(department: string) {
  filters.department = department;
  setFilters(filters);
}

// Right: build a new object with the change applied.
function chooseDepartment(department: string) {
  setFilters((current) => ({ ...current, department }));
}

// Right: non-mutating array operations return new arrays.
function select(id: string) {
  setSelectedIds((current) => [...current, id]);
}

function deselect(id: string) {
  setSelectedIds((current) => current.filter((item) => item !== id));
}

• React decides whether state changed by comparing the old value with the new one by identity. Mutate an object in place and both sides are the same object, so nothing is considered changed.
• The spread copies the existing keys into a new object, then the later key wins. { ...current, department } reads as "everything as it was, with a different department".
• filter, map, slice and concat return new arrays. push, splice, sort and reverse change the array in place — if you need a sorted copy, sort a spread of it, or use toSorted where your runtime supports it.
• The spread is shallow. A nested object is still shared with the previous state, so updating a value two levels down needs a copy at each level. When that becomes awkward, it is a sign the state shape should be flatter.