The aria-live polite approach is correct but there's a subtlety worth knowing: some screen readers throttle polite regions if updates come too fast, so you might want to batch your live region updates the same way you batch visual updates, rather than updating it on every single token. Some implementations use a separate visually-hidden div as the live region and only push text to it every few hundred milliseconds. For testing, a fake ReadableStream backed by an async generator is the right shape. You yield chunks with small awaits between them, wrap it in a Response object so it looks like a real fetch response, and then your component code doesn't need to know it's fake. The deterministic part means controlling exactly when each chunk arrives, which lets you assert intermediate states like that the streaming bubble shows partial text before the final chunk lands.

Nice practical question. I'd track a boolean in a ref (not state, no need to re-render) that flips to false when the user scrolls up past a threshold, say 100px from the bottom. On each new chunk, if that ref is true, call scrollIntoView or set scrollTop on the container. When the user scrolls back down to the bottom, flip the ref back to true. The scroll listener needs to be passive and probably debounced slightly so it's not firing on every pixel of scroll.

Pretty much exactly what you described. The one thing I'd add is that the button label itself can do some work here: during streaming it says Stop Generating, after stopped it could say Resume or just go back to the send icon. That label state is derivable from your status enum so you're not managing extra booleans. The AbortError catch is the part candidates most often miss, and it's the part that makes the feature feel polished versus janky.

Scoping the streaming updates to a ref inside the last bubble is the key insight. If your messages array lives in state and you append a character to the in-progress message on every chunk, every message bubble re-renders. Instead, keep the in-progress text in a ref and have only the active bubble subscribe to it, maybe via a context or just by passing a ref down. Older bubbles are static and never touch that ref, so they're completely inert during streaming. Virtualization is worth mentioning for very long conversations but the ref scoping gets you most of the way there without the complexity of a virtual list.

The boolean trap is so real. I did the exact same thing at a different company, ended up with isLoading, isStreaming, isError, isDone, and then the conditional logic for what the button should look like became this gnarly nested mess. A status enum collapses all of that: one field, exhaustive switch, done. For the TextDecoder thing, don't be too hard on yourself, that's genuinely obscure. The reason you need to reuse the same instance with stream: true is that a multi-byte UTF-8 character like an emoji can be split across two separate Uint8Array chunks, and a fresh decoder on each chunk would misinterpret the partial byte sequence. The stateful decoder holds the incomplete bytes in an internal buffer and flushes them when the next chunk arrives. I only knew this because I hit the bug in production first and then went spelunking through the spec. The component structure I'd reach for is pretty flat: one parent that owns the status enum and the messages array, a controlled input, and a message bubble component that for the streaming case reads from a ref rather than state so you're not triggering a full React reconcile on every token. The ref gets flushed into state at natural pause points or on completion.

Increment a requestId counter on each submission, capture the value in the closure, and after every await check if the captured id still matches the current ref. If not, return early. Two lines of code, prevents a whole class of bugs. AbortController handles the network side but this check handles the React side.

The await-yields-to-event-loop point is the crux of it. Each iteration of your read loop does await reader.read(), and that await is a microtask checkpoint. The browser gets to process paint frames and input events between chunks. So the loop isn't blocking even though it looks synchronous. Where you can still get into trouble is if you call setState on every single chunk and React schedules a synchronous re-render each time. Batching helps: accumulate chunks into a ref, then flush to state either on requestAnimationFrame or after a small debounce. The visual difference is imperceptible to users but the frame budget difference is real.

The abort-on-unmount piece is easy to forget and it matters a lot in a Next.js app where route transitions can leave a fetch dangling. But the user-abort-vs-network-error distinction is the actually interesting bit. When you call controller.abort(), fetch rejects with a DOMException whose name is AbortError. If you catch all errors the same way and set status to error, you get a red error banner when the user just clicked Stop, which looks broken. The fix is a simple name check in your catch block: if err.name === 'AbortError' and the abort was user-initiated (you can track this with a ref flag), transition to stopped or idle and keep the partial text. If it's a real network failure, then show the error state. One thing I'd add: store the AbortController in a ref, not state, so creating a new one for each submission doesn't trigger a render.