Hooks Traps: Stale Closures, Effect Loops and Dependencies

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Closure

A function together with the variables it could see when it was created.

Stale closure

A function that keeps reading values from an old render because it was created then and is still being called.

Updater function

A function passed to a setter, setCount((c) => c + 1), that receives the latest queued value.

Dependency array

The list after an effect telling React which values it reads; the effect re-runs when one changes.

Effect loop

An effect that sets state, which re-renders, which makes the effect run again, without end.

Referential equality

Two objects are equal only if they are the very same object. {} is never === another {}.

Cleanup

The function an effect returns; React runs it before the effect runs again and on unmount.

useEffectEvent

A React 19.2 hook that makes a function for effects that always sees the latest props and state, without being a dependency.

1. 1

   Fix the stale counter with dependencies instead

   In Trap 1, keep setCount(count + 1) but change the deps to [count] and move let ticks outside the component (so it survives restarts). Predict: does it reach 5? (Yes, but the interval is torn down and restarted after every tick. Correct, but wasteful: the updater is the better fix.)

2. 2

   Remove the safety stop in your head first

   In the loop demo, what would happen without if (renders > 60) return;? Don't run it: reason it out. Then apply the fix from the next example to this one and check the render count drops to 2.

3. 3

   Wrap the leak in StrictMode

   Wrap the leaky demo's two components in <StrictMode> (import it). Predict how many leaky lines print now. (Five: StrictMode's extra mount added one more listener that was never removed, while the clean component still prints one line.)

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   A closure is a function plus the variables it could see when it was created (see /javascript, closures). Every render of a component is a fresh function call with its own count, its own props and its own handlers (Topic 4.4: state as a snapshot). A handler or effect created in render 1 closes over render 1's count. That is correct most of the time. It becomes a bug when the function lives longer than its render: an interval started once, a setTimeout, an await in the middle of a handler, a subscription callback.

2. 2

   Trap 1: the interval that stops at 1. useEffect(() => { setInterval(() => setCount(count + 1), 1000) }, []) runs once, so the interval callback forever sees count = 0 and keeps setting 1. Fixes, best first: an updater setCount((c) => c + 1) (no need to read count at all); list the value in the deps so the effect re-syncs (restarts the interval each time); or read the latest value through a ref or useEffectEvent (Topic 7.9, React 19.2) when the callback must read something without restarting the effect. The react-hooks/exhaustive-deps lint rule catches the original mistake and even suggests the updater.

3. 3

   Trap 2: the async handler that reads old state. In async function checkout() { await save(); console.log(qty) }, qty is the value from the render where the click happened, even if the user changed it during the await. Often that is what you want (send what the user saw when they clicked). When you really need the newest value, keep it in a ref updated each render, read it from the server's response, or pass it as an argument. Don't "fix" it by adding a setTimeout.

4. 4

   Trap 3: the effect loop. An effect that sets state re-renders the component; if a dependency changes on every render, the effect runs again, sets state again, and so on. The usual culprit is an object, array or function created during render used as a dependency: { query } is a new object each render, and React compares dependencies with Object.is (Topic 7.2), so it always looks changed. React's development build detects this and prints Maximum update depth exceeded. Fixes: depend on primitive values (query instead of options), create the object inside the effect, move constants outside the component, or memoise with useMemo/useCallback (Topic 16.4). Also ask whether the effect is needed at all: derived data should be computed during render (Topic 7.6).

5. 5

   Trap 4: the missing cleanup. Every effect that subscribes, listens, starts a timer or opens a connection must return a cleanup that undoes it (Topic 7.3). Without it, each re-run adds another listener, and the old ones still run with their old closed-over values: a leak and a stale closure at once. StrictMode's mount → unmount → mount in development (Topic 7.4) exposes this immediately by doubling the effect.

6. 6

   How to debug any of these. Ask three questions: which render created this function? Which values does it read? Does it live longer than that render? Then pick the tool: an updater for "next from previous", correct dependencies for "re-sync when this changes", a ref or useEffectEvent for "read the latest without re-syncing", and a cleanup for "undo what I started". Turn on eslint-plugin-react-hooks: its exhaustive-deps rule flags missing dependencies and objects that change every render, and version 7 also ships the React Compiler-powered rules (Topic 16.5).

• ↔

  Updaters and correct deps keep code reactive and simple; refs and useEffectEvent are escape hatches that make it easy to hide real dependencies, so use them only for genuinely non-reactive reads.

• ↔

  Memoising dependencies fixes loops but adds code; often the better fix is removing the effect and computing during render.

• I can explain and demo a stale closure in an interval and in an async handler.

• I can pick between an updater, deps, a ref and useEffectEvent.

• I can spot and fix an effect loop caused by an object dependency.

• I write a cleanup for every effect that starts something.

• I can read the exhaustive-deps lint messages and act on them.