The compiler does not fix this
React Compiler auto-memoizes what you would have memoized by hand, which is precisely the class of fix that does nothing for a stream — it changes who writes the memo, not whether a render per chunk is the wrong shape.
The memoization lesson ends somewhere uncomfortable: the fix everyone reaches for is theatre, and doing it properly means splitting boundaries and stabilising props by hand across a component tree. So the next suggestion arrives on its own. Turn on React Compiler. It writes all of that for you.
It does. That is not the objection. The objection is that writing the memoization for you is a solution to the problem you did not have.
What the compiler says it does
react.dev’s React Compiler page describes the mechanism in one clause: it works by “handling memoization for you, eliminating the need for manual useMemo, useCallback, and React.memo.”
The same page names the two problems it is aimed at:
- Re-rendering a parent causes many components in its tree to re-render even though only the parent changed.
- Expensive calculations run again when they did not need to, including work that came from outside React.
Both are real and both are worth fixing. Look at what neither of them is. Neither says anything about when React decides a component must re-render because its own state changed. That decision is untouched. The compiler changes whether cached work can be reused within a render that was going to happen anyway.
The sentence that settles it
Your streaming code calls setState on every chunk. A state update schedules a render. Compile the file and it still calls setState on every chunk, and the render is still scheduled. The compiler has no opinion about your event handler.
This is the same precondition failure as the last lesson, one level up. Hand-written memo could not help because the props were new every chunk. Compiler-written memoization cannot help for exactly the same reason: it is the same technique, applied by a different author, to the same inputs. Automating a fix does not change which class of problem the fix belongs to.
What the compiler genuinely buys you here
“The compiler does nothing for a streaming surface” is the overcorrection, and it is false. Look again at the first problem it targets: re-renders that propagate to components that did not change. A streaming panel is usually not alone on the page. It sits beside a header, a settings menu, a document viewer, a sidebar — and if any of those live under a shared parent that re-renders on every chunk, they re-render too.
That is wasted work, it scales with everything else on the page, and it is precisely the class the compiler removes. On a surface grafted into a host application, where you do not control what shares your subtree, it can be a meaningful win. It is a win on render cost, alongside the per-message boundaries from the last lesson, not a win on render count.
So the honest position is narrow and worth stating in exactly these terms: React Compiler does not change how often the state updates driving your stream cause a render. It may still reduce what each of those renders costs, and what they cost the components around them.
Dating the claim, because this one moves
Advice about the compiler goes stale faster than almost anything else in React, because its status changed twice in a year. Per react.dev’s versions page, the compiler reached beta on 21 October 2024 and version 1.0 on 7 October 2025. The current stable React line is 19.2.
This matters for a specific reason. A 2025 blog post telling you the compiler is experimental and should not be used in production is describing a state of the world that ended, and a 2024 post telling you it is the answer to re-render problems was written before most people had run it. Check the date on anything you read about it, including this page, and check it against the versions page rather than against memory. The course’s standing rule — every threshold and every status claim carries a date — exists for cases exactly like this one.
Where people get burned
Adopting the compiler is not free of risk on a guest surface. It optimises only components that follow the Rules of React, and a codebase that has been getting away with a mutation during render will find out. Budget time for the bailouts it reports rather than assuming a clean build means a clean tree. That is an adoption cost worth paying on its own merits. It is not a cost worth paying because you expect it to move INP under a stream.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
If the compiler removes the need for hand-written memo, why did the previous lesson spend its time on splitting boundaries and stabilising props?
Check your answer
Because splitting a boundary and stabilising a prop are two different acts, and the compiler only automates one of them. It writes the caching. It does not restructure your component tree so that the changing part is small, and it does not stop your parent from rebuilding completed message objects out of raw accumulator state on every chunk.
Put another way: the compiler removes the boilerplate of memoization, not the design work that makes memoization possible. A tree whose props are all structurally new every render is a tree the compiler has nothing to cache in, and it will compile cleanly and change nothing you can measure.
That is the version of this lesson worth carrying into a design review, because it also tells you when the compiler is the right call: on a tree whose data is already stable and whose memoization is merely missing or wrong.
Hands on
Settle the compiler question with a measurement rather than a debate
Done when: MEASUREMENTS.md carries a render count during one stream, taken with and without the compiler enabled at the same throttling setting and the same prompt, plus one line stating whether the count changed.
- Instrument the render count directly. Increment a counter in the transcript’s
onRendercallback from the<Profiler>you added in the memoization lesson, and read it once when the stream finishes. A count is the number this lesson turns on, so measure it rather than inferring it from stack shapes in a trace. - Run one stream to completion with the compiler off. Record the render count, the transcript length, the prompt and the throttling preset.
- Enable the compiler for the surface. Confirm it actually applied — check its output or bailout reporting rather than assuming the build flag was enough. A compiler that silently bailed out of your component makes the whole comparison meaningless.
- Run the same prompt again. Record the render count a second time, along with
actualDurationandbaseDurationfrom the same Profiler. - Write the verdict in one line. The count should be unchanged, which is this lesson’s claim; the durations may have fallen, which is the compiler’s genuine contribution. If the count did change, something else changed with it and you need to find out what before you trust either run.
- Bring both counts into the chat with the bailout status. I will push back if the compiler was not verified as applied, or if the two runs used different prompts.
What this does not cover
Two lessons have now established what does not move the number. The keeping-the-stream-out-of-state lesson is where the render count comes down, by taking the accumulator out of React state entirely and flushing on a schedule you pick rather than one the model picks. That lesson is also careful about when it helps, because it is not the fix for every phase.
This lesson does not teach compiler adoption: the Rules of React it depends on, how to read its bailout output, and how to roll it out directory by directory are all on react.dev’s own page, which is the primary source above and is worth reading in full before you propose it to anyone.
It also says nothing about what your surface ships into the host’s bundle. The compiler adds a runtime dependency and changes your output; whether that is affordable as a guest is a payload question, and the payload module handles marginal cost to a page you did not write. The stream’s transport and lifecycle remain the Streaming interfaces course’s.
Read this next — primary source
React Compilerreact.dev — free; fetched 5 September 2026, no revision date shown on the page. Meta documenting its own compiler.
This lesson takes the compiler’s own statement of what it optimises and the two problems it says it targets. The full page adds the parts a lesson has to compress: what the compiler requires of your code before it will optimise a component at all, how it reports bailouts, how to check what it did rather than assume, and the incremental adoption path for a codebase that cannot switch everything at once. Read it before you argue that a codebase is ready for it, because most of the argument is about the rules, not the wins.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.