Transitions under a stream that never stops

You have the render count down and the store publishing on a cadence you chose. One question is left, and it is the one the stop button has been asking since the first lesson: when a click arrives while React is halfway through rendering a transcript, who wins?

React has an answer, it is a real guarantee, and it degrades in a specific way under a stream that never stops. Both halves matter, and most writing about this covers only the first.

The guarantee

From react.dev’s useTransition reference:

A state update marked as a Transition will be interrupted by other state updates. For example, if you update a chart component inside a Transition, but then start typing into an input while the chart is in the middle of a re-render, React will restart the rendering work on the chart component after handling the input update.

Substitute the chart for your transcript and the typing for a stop click, and that paragraph is the feature this module has been working toward. Urgent input preempts low-priority render work. The click is handled first, the transcript render resumes afterwards.

const [isPending, startTransition] = useTransition()

function onFlush(next) {
  startTransition(() => setTranscript(next)) // interruptible by the stop click
}

The degradation

Read the last four words of the quote again: React will restart the rendering work. Not resume. Restart.

The useDeferredValue reference states the same mechanism from the other side and takes it to its conclusion:

The background re-render is interruptible: if there’s another update to the value, React will restart the background re-render from scratch. For example, if the user is typing into an input faster than a chart receiving its deferred value can re-render, the chart will only re-render after the user stops typing.

Now substitute again, and notice that the substitution is not the one you expected. It is not the user typing. It is the model streaming. If the deferred or transitioned value changes on every flush, and a flush arrives before the low-priority render finishes, the render restarts from scratch. Flush often enough and it may never commit at all.

The documented consequence for the chart is that it renders only after the typing stops. The consequence for your transcript is that it renders only after the stream stops, which is a frozen answer with a cursor blinking at the top of it. React is behaving exactly as documented. Your flush cadence made the low-priority work unschedulable.

What a Transition is not

The useDeferredValue page is direct about the boundary, and the sentence is worth memorising because it stops a whole class of bad proposals: deferring a value “does not make re-rendering… faster,” it tells React that the re-render can be deprioritised.

Transitions and deferred values are scheduling tools. They change the order in which work happens and what can interrupt what. They do not make a render cheaper, they do not reduce the number of renders, and they cannot help a phase that is not about competition for the main thread. Line them up against the three phases:

• Input delay. This is where a Transition can help, because input delay is by definition the click waiting behind other work, and interruptibility is a claim about exactly that.
• Processing duration. Untouched. Your handler runs at the same speed.
• Presentation delay. Mostly untouched, and possibly worse, since restarted background renders are work the browser did and threw away.

The async limitation you will hit

One documented restriction bites immediately in stream code. Per the reference, you must wrap any state updates that happen after an async request in another startTransition to mark them as Transitions. React describes this as a known limitation it intends to fix.

A stream handler is nothing but state updates after an async request. The update you issue inside a .then(), or after an await on the next chunk, is not a Transition just because the function that started the read was wrapped in one.

// Not a Transition: the await ends the scope
startTransition(async () => {
  const chunk = await reader.read()
  setTranscript(chunk.value)          // urgent, despite appearances
})

// A Transition: re-wrap after the await
const chunk = await reader.read()
startTransition(() => {
  setTranscript(chunk.value)
})

This one is hard to catch by reading, because both versions compile, both run, and the difference shows up only as a priority you thought you had assigned and did not. Verify it in a profile rather than in review.

What this does not cover

That closes the render-cost half of this course. You can now say which of the standard React fixes applies to which phase, and prove it: memo boundaries and the compiler reduce what a render costs, the ref-and-flush pattern reduces how often renders happen, the external store makes that readable without tearing, and Transitions decide what a click is allowed to interrupt.

None of it makes the transcript smaller. If your phase split still names presentation delay after all of this, the remaining cost is the DOM itself and the work of turning tokens into it. That is the payload module: what you ship into the host’s bundle, virtualizing a conversation whose last message grows while it is on screen, and the cost of re-parsing markdown on every chunk. Those are the lessons for a trace that this module could not move.

And the stream itself is still not this course’s subject. Transports, event shapes, aborting the request the stop button fires, resuming after a refresh, retry and backoff — all of that is the Streaming interfaces course. This one has only ever asked what the browser is spending once the bytes are already arriving, and what evidence you can put in front of a team whose page you are a guest on.