Stale closures, refs and useEffectEvent

At kickoff the coach hands a substitute a card, "0–0: keep pressing", and sends him on. Every five minutes he acts on what the card says.

In the analogy	In React
The card written at kickoff	The values the effect's callback closed over (step 1)
After two goals he still presses, because the card still says 0–0	A [] interval reading the first render's state (step 2)
Each goal sends on a fresh player whose five-minute routine starts from zero; with a goal every two minutes, nobody ever acts	The cost of listing a value: every change restarts the interval's count (step 4)
A card that says "one step beyond wherever you stand now"	An updater: works from the current value, needs no new card (step 5)
He glances at the stadium scoreboard each time he acts	A ref or Effect Event: read at fire time (steps 7–9)

Breaks down when:

• A scoreboard updates itself; a ref changes only when your code writes it. Wrong inference: "a ref follows state automatically."
• Anyone may read a scoreboard; an Effect Event may be called only from Effects or other Effect Events, not during render or by a child. Wrong inference: "pass it down as a prop."

Contrasting case: the coach shouting one instruction when the ball goes out. That is a click handler: React creates it in each render, and the handler that runs belongs to the render the candidate is looking at.

In real terms: an effect's callbacks read the render that set them up; re-running the effect refreshes them by replacing the subscription, while refs and Effect Events refresh the read instead.

Example 1: the ExamHall countdown, three ways

The exam starts at 90:00 (5400 s). Each version runs 5 virtual seconds.

useEffect(() => {
  const id = setInterval(() => setSecondsLeft(secondsLeft - 1), 1000);   // A and B
  // C: setInterval(() => setSecondsLeft((s) => s - 1), 1000)
  return () => clearInterval(id);
}, []);            // B: [secondsLeft]

A  [] + setSecondsLeft(secondsLeft - 1)            after 5 s: 89:59 | interval setups=1 cleanups=0
B  [secondsLeft] + setSecondsLeft(secondsLeft - 1) after 5 s: 89:55 | interval setups=6 cleanups=5
C  [] + setSecondsLeft(s => s - 1)                 after 5 s: 89:55 | interval setups=1 cleanups=0

A is stuck: every tick computes 5400 − 1 (step 2). B is right but replaces its interval on every tick (steps 3–4). C is right with one interval, because the updater reads pending state (step 5).

Example 2: EXH-469, the backup that sends an empty answer

The 5 s backup had [] and called backup(answer), so it sent the first render's empty answer. MR !793 reads the answer through an Effect Event. The candidate types "Ohm" at 2 s and "Ohm's law" at 7 s.

const onBackup = useEffectEvent(() => backup(answer));      // MR !793
useEffect(() => {
  const id = setInterval(() => onBackup(), 5000);
  return () => clearInterval(id);
}, []);                                                       // onBackup is not listed
// ref variant: const latest = useRef(answer); useEffect(() => { latest.current = answer; }); … backup(latest.current)
// NOT variant: the same ref without the effect that writes it

BUG   [] deps, reads answer          backups: 5s:"" 10s:"" | interval setups=1
FIX   useEffectEvent (MR !793)       backups: 5s:"Ohm" 10s:"Ohm's law" | interval setups=1
ALSO  ref written in an effect       backups: 5s:"Ohm" 10s:"Ohm's law" | interval setups=1
NOT   useRef(answer), never written  backups: 5s:"" 10s:"" | interval setups=1

An updater could not help here: the backup sends data, it does not compute state (step 6). The Effect Event and the written ref both read the latest answer with one interval (steps 8–9). The unwritten ref keeps useRef's first value, the empty answer, because nothing assigns .current (step 7).