Cleanup and stale closures

Whatever an effect starts, its cleanup must stop — the return function is not optional decoration. React calls the cleanup before the effect re-runs (because a dep changed) and once more on unmount. If you skip it, the old subscription, interval, or listener keeps running alongside the new one. The mental model: setup and cleanup come in pairs, and at any moment exactly one subscription should be live.

useEffect(() => {
  const socket = createConnection(roomId);
  socket.connect();
  return () => socket.disconnect(); // pairs with connect
}, [roomId]);

When roomId changes, React runs cleanup for the old room then setup for the new one. Drop the return and every room change leaks another open connection — and every connection still fires its handlers into a component that has moved on.

An effect captures the values of the render that created it — that’s the stale closure, and it’s a feature, not a bug. The function you pass to useEffect closes over the props and state from that render. If the deps array doesn’t list a value the effect reads, the effect keeps using the value frozen at the render it last ran on. With [], that’s the very first render, forever.

function Poller({ onTick }: { onTick: (n: number) => void }) {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      // BUG: `count` is frozen at 0 — this closure was created on the
      // first render and [] never lets React make a fresh one.
      setCount(count + 1); // always 0 + 1 → stuck at 1
    }, 1000);
    return () => clearInterval(id);
  }, []); // lies: the effect reads `count` but doesn't list it
  return <p>{count}</p>;
}

The interval runs forever, but it forever computes 0 + 1. The closure is correct React semantics; the deps are the lie.

Fix a stale closure by removing the dependency, not by hiding it: a functional update, or a ref for values you only read. The interval doesn’t actually need the current count value — it needs to increment whatever the latest count is. A functional update expresses exactly that, and now the effect reads no state, so [] is honest.

useEffect(() => {
  const id = setInterval(() => {
    setCount((c) => c + 1); // React supplies the latest value
  }, 1000);
  return () => clearInterval(id);
}, []); // honest now — the effect closes over nothing reactive

When you must read the latest value (not just transform it) inside a long-lived callback — say the freshest onTick prop — write it to a ref and read ref.current, so the interval is never recreated yet always sees today’s value:

const onTickRef = useRef(onTick);
useEffect(() => { onTickRef.current = onTick; }); // every render, keep it fresh
useEffect(() => {
  const id = setInterval(() => onTickRef.current(Date.now()), 1000);
  return () => clearInterval(id);
}, []); // interval created once; ref bridges to the latest prop

A fetch is a subscription too: cancel the in-flight request in cleanup with AbortController, or fast deps race slow responses. When the dep changes faster than the network responds, two requests are in flight and the slower one can resolve last, overwriting the correct data. Cleanup aborts the stale request so only the current one can commit.

useEffect(() => {
  const ctrl = new AbortController();
  fetch(`/api/users/${userId}`, { signal: ctrl.signal })
    .then((r) => r.json())
    .then(setUser)
    .catch((err) => {
      if (err.name !== "AbortError") setError(err); // ignore our own abort
    });
  return () => ctrl.abort(); // cancel the stale request on userId change/unmount
}, [userId]);

Without the abort, switching userId from 1 → 2 → 3 can leave user 1’s response committing after user 3’s, and a setUser firing after unmount. The abort closes both holes — leak and race — in one line.