Effects as synchronization

A building takes power from one source at a time: the grid or its generator. An open-transition transfer switch changes source break-before-make: it opens the old source, then closes onto the new one, so the two are never connected together.

In the analogy	In React
The source feeding the building	The dependency values
The meter reading changes while the source stays the grid: no transfer	A re-render with Object.is-equal dependencies: no re-run
Transfer: open the old source, then close onto the new	Dependency change: previous cleanup, then new setup
Shutting the building down opens the switch	Unmount runs the cleanup
At commissioning, the first connection is opened and closed once to prove the switch opens	Development StrictMode's extra setup → cleanup on mount
The panel's load figure is calculated from the readings; nobody throws a switch for it	A derived value is computed during render

Breaks down when:

• Opening a switch cuts the current at once, but an in-flight network response still arrives after cleanup. Wrong inference: "cleanup alone stops a late response." It must be ignored or aborted (step 6).
• The switch acts by itself; React runs only the cleanup you wrote. Wrong inference: "React disconnects the old subscription for me."
• An electrician calls it the same source if it is the same grid; React compares identity. Wrong inference: "an object rebuilt with equal fields counts as unchanged."

Contrasting case: a technician presses the switch's test button because someone asked for a test, not because of which source is live. That is an event handler (step 8).

In real terms: after each commit, React compares every effect's dependencies with the previous run's; for each changed one it calls the stored cleanup, then the new setup, and it calls all cleanups on unmount.

Outputs are the literal stdout of the scripts named, 50/50 identical sequential and under 8-parallel load. Socket and fetch fakes are settled by the script, never by a timer.

Example 1 · ExamHall EXH-492: the old socket streams into the new view

InvigilatorCam opens a hall-camera socket per hallId. The invigilator switches from hall-A to hall-B; then the server sends one alert for each hall.

useEffect(() => {
  const ws = server.connect(hallId);
  ws.onmessage = (a) => setAlerts((list) => [...list, `${a.text} (${a.from})`]);
  return () => ws.close();            // MR !829 adds this line
}, [hallId]);

no cleanup | StrictMode off | open hall-A > open hall-B | open after mount: 1, at end: 2
                            | screen: viewing hall-B: seat 12 empty (hall-A), late arrival (hall-B)
no cleanup | StrictMode on  | open hall-A > open hall-A > open hall-B | open after mount: 2, at end: 3
                            | screen: viewing hall-B: seat 12 empty (hall-A), seat 12 empty (hall-A), late arrival (hall-B)
cleanup    | StrictMode off | open hall-A > close hall-A > open hall-B | open after mount: 1, at end: 1
                            | screen: viewing hall-B: late arrival (hall-B)
cleanup    | StrictMode on  | open hall-A > close hall-A > open hall-A > close hall-A > open hall-B | open after mount: 1, at end: 1
                            | screen: viewing hall-B: late arrival (hall-B)

Without cleanup, hall-A's socket keeps delivering into hall-B's view (step 4). StrictMode exposes the bug at mount: two sockets for one hall. With cleanup, StrictMode's extra cycle leaves one socket (step 5).

Example 2 · Catalog: a slow first response wins the race

ProductPage fetches in an effect keyed on productId. The shopper opens p-1, then p-2; the script resolves p-2 first and p-1 second.

useEffect(() => {
  let ignore = false;
  fetchProduct(productId).then((p) => { if (!ignore) setProduct(p); });
  return () => { ignore = true; };    // or: const ac = new AbortController(); … return () => ac.abort();
}, [productId]);

naive           | after p-2 arrives: url p-2 | showing Trail shoe | after p-1 arrives: url p-2 | showing Rain jacket
ignore          | after p-2 arrives: url p-2 | showing Trail shoe | after p-1 arrives: url p-2 | showing Trail shoe | dropped p-1
abortcontroller | after p-2 arrives: url p-2 | showing Trail shoe | after p-1 arrives: url p-2 | showing Trail shoe | p-1 fetch: AbortError

Without a guard, the late p-1 response overwrites p-2. The ignore flag drops it; aborting rejects it. Neither undoes the server's work (step 6); signals and server-side limits are in js-abort-cancellation.

Example 3 · Ticketing: you might not need an effect

OrderSummary shows a total derivable from price and qty. A layout effect records the DOM after each commit; qty goes from 1 to 2.

// A: const [total, setTotal] = useState(price * qty);
//    useEffect(() => { setTotal(price * qty); }, [price, qty]);
// B: const total = price * qty;

A effect + state  | qty 1 -> 2: renders 2, commits 2: "2 tickets, total €10" then "2 tickets, total €20"
B computed        | qty 1 -> 2: renders 1, commits 1: "2 tickets, total €20"

The effect version commits a wrong total, then renders again (step 7).