Transitions and concurrent rendering

She works alone at one board, drawing tomorrow's strip panel by panel, while the editor phones with quick questions.

At the board	In React
she answers the editor's call between panels	an urgent update commits first (step 2)
today's paper keeps the old strip; a note says "new strip coming"	the old results stay; isPending (steps 2–3)
she never stops in the middle of a panel	React yields between components, never inside one (step 4)
the news changes: the half-drawn strip goes in the bin, and she starts again from panel one	a half-done render is thrown away and redone with the newest state (step 5)
answering calls never draws the strip faster	not faster (step 6)

Breaks down when: she keeps the panels the news did not touch; React discards the whole unfinished render. Wrong inference: "React resumes where it stopped".

Contrasting case: a debounce waits for the input to go quiet before any work starts (js-debounce-throttle); a Transition starts at once and is redone only when overtaken.

In real terms: a Transition is a lower-priority render that React may abandon and redo; it keeps urgent commits flowing, running the same code on the same thread.

4.1 ExamHall: EXH-3320 and MR !3620

The pilot kept one query state for the box and the table, and ResultsTable was a plain component: every key re-rendered all 40 session groups before the box could show it. MR !3620 keeps text urgent, sets query in a Transition and wraps ResultsTable in memo (steps 1–3, 8):

// EXH-3320, the pilot
<input value={query} onChange={(e) => setQuery(e.target.value)} />
<ResultsTable sessions={sessions} query={query} />

// MR !3620
<input value={text} onChange={(e) => {
  setText(e.target.value);
  startTransition(() => setQuery(e.target.value));
}} />
{isPending && <span>Updating…</span>}
<ResultsTable sessions={sessions} query={query} />   // ResultsTable = memo(…)

4.1 EXH-3320 pilot (one state): key "z" · 1 commit: box "z", table 6,800 rows · SessionGroups rendered before the box shows "z": 40
4.1 MR !3620 (Transition): key "z" · commit 1: box "z", table all 50,000 rows, "Updating…" shown · SessionGroups rendered before it: 0
4.1 MR !3620 (Transition): commit 2: table 6,800 rows, "Updating…" gone · SessionGroups rendered for it: 40
4.1 SessionGroups rendered per key: pilot 40, MR 40

The box no longer waits for the table. For one key, the table still renders all 40 groups: the work moved, it did not shrink (step 6).

4.2 Media streaming: a podcast episode search with a deferred value

EpisodeList gets the box's text as query and defers it itself; only the grid inside it, wrapped in memo, reads the deferred value (steps 7–8):

<input value={text} onChange={(e) => setText(e.target.value)} />
<EpisodeList shows={shows} query={text} />

// inside EpisodeList({ shows, query })
const deferredQuery = useDeferredValue(query);
<h2>Episodes for "{query}"</h2>
<ShowGrid shows={shows} query={deferredQuery} />   // ShowGrid = memo(…)

4.2 40 shows · key "n" · render 1 (urgent): box "n", heading "n", grid for "" · ShowRows rendered: 0
4.2 render 2 (background): heading "n", grid for "n" · ShowRows rendered: 40

In the urgent render one component holds two values: the heading already says "n" while the grid still gets "", so memo skips it. The background render draws the grid with the new text.