Effects, and When You Do Not Need One

An effect is code that runs after a render and reaches outside React. Setting the document title, starting a timer, subscribing to a browser event, opening a connection, measuring an element.

useEffect exists for one job: keeping something outside React in step with the state inside it. Read that as a restriction rather than a description. The majority of effects written by people learning React are not synchronising with anything external, and the code is shorter, faster and more correct without them.

So this lesson is in two halves. First, the cases where an effect is the wrong tool — that is where the bugs are. Then the dependency array and cleanup, for the cases where it is right.

"use client";

import { useEffect, useState } from "react";

function EmployeeDirectory({ employees }: { employees: Employee[] }) {
  const [term, setTerm] = useState("");
  const [matches, setMatches] = useState<Employee[]>([]);
  const [matchCount, setMatchCount] = useState(0);

  // Everything below is avoidable.
  useEffect(() => {
    const filtered = employees.filter((employee) =>
      employee.name.toLowerCase().includes(term.toLowerCase())
    );
    setMatches(filtered);
    setMatchCount(filtered.length);
  }, [employees, term]);

  return (
    <>
      <input value={term} onChange={(event) => setTerm(event.target.value)} />
      <p>{matchCount} results</p>
      <EmployeeTable employees={matches} />
    </>
  );
}

• Follow one keystroke. React renders with the new term but the old matches, commits that to the screen, then runs the effect, which sets state and causes a second render. The user briefly sees results that do not match what they typed.
• The first render of the component shows zero results regardless of the data, because matches starts as an empty array and the effect has not run yet.
• matchCount is a third copy of information already present in matches.length. Two pieces of state that must agree, maintained by hand.
• The effect list has to stay complete and correct forever. Add a department filter, forget to add it to the dependencies, and the results stop updating for that filter only — with no error anywhere.

"use client";

import { useState } from "react";

function EmployeeDirectory({ employees }: { employees: Employee[] }) {
  const [term, setTerm] = useState("");

  const matches = employees.filter((employee) =>
    employee.name.toLowerCase().includes(term.toLowerCase())
  );

  return (
    <>
      <input value={term} onChange={(event) => setTerm(event.target.value)} />
      <p>{matches.length} results</p>
      <EmployeeTable employees={matches} />
    </>
  );
}

• One piece of state instead of three. One render per keystroke instead of two. No dependency array to keep in step, and no window in which the screen shows stale results.
• The first render is correct, because matches is calculated before anything is displayed rather than after.
• Adding a department filter means adding one piece of state and one clause to the filter. Nothing else can fall out of date, because nothing else is stored.
• The test for whether you need an effect: could this value be calculated from what I already have? If yes, calculate it. Only reach for an effect when the answer involves something outside React entirely.

"use client";

import { useEffect, useState } from "react";

/** True while the viewport is at or above the given width. */
export function useIsWideScreen(minWidth = 1024) {
  const [isWide, setIsWide] = useState(false);

  useEffect(() => {
    const query = window.matchMedia("(min-width: " + minWidth + "px)");

    // Set the current value, because the query may already match.
    setIsWide(query.matches);

    function handleChange(event: MediaQueryListEvent) {
      setIsWide(event.matches);
    }

    query.addEventListener("change", handleChange);

    // Cleanup: remove the listener when the dependency changes
    // or the component is removed.
    return () => query.removeEventListener("change", handleChange);
  }, [minWidth]);

  return isWide;
}

• This is genuine synchronisation. The viewport width lives in the browser, not in React, and nothing in state or props can tell you about it.
• The effect sets the current value first. Without that, the state stays false until the width happens to cross the threshold, which may never occur.
• The returned function is the cleanup. React runs it before the effect runs again, and once more when the component is removed. Without it, every remount adds another listener and the old ones keep calling setState on components that no longer exist.
• minWidth is in the dependency array because the effect uses it. Change the prop and React cleans up the old listener and sets up one for the new query — which is what synchronisation means in practice.
• Note that isWide starts as false rather than being read during render. Reading the viewport while rendering breaks server rendering, because there is no window on the server. Starting with a value and correcting it in the effect is the usual way to handle browser-only information.