Using the browser Fetch API, how do you consume a response incrementally instead of awaiting response.text(), and what problem does piping response.body through a TextDecoderStream solve?

## Two ways to take a body A `fetch()` promise resolves as soon as the response *headers* have been received; the body may still be arriving over the network. The convenience methods — `response.text()`, `response.json()`, `response.blob()` — each buffer the whole body and resolve only when the last byte lands. For a 40 KB JSON document that is exactly what you want. For a large export, a progress UI, or a token-by-token model response it is the wrong shape: nothing can be shown until everything has arrived, and the entire payload sits in memory at once. The alternative is `response.body`, a `ReadableStream` whose chunks are `Uint8Array` values. It is `null` for a response that has no body at all, so a defensive read checks for it. ## The read loop ```js const res = await fetch('/export.ndjson'); if (!res.ok) throw new Error(`HTTP ${res.status}`); if (!res.body) throw new Error('no body to stream'); const reader = res.body.getReader(); for (;;) { const { value, done } = await reader.read(); if (done) break; // value is undefined on the final read console.log(value.byteLength); // value is a Uint8Array } ``` `getReader()` **locks** the stream: while a reader is attached nothing else may read it, and a second `getReader()` throws. `reader.releaseLock()` gives the stream back; `reader.cancel()` discards the rest. `read()` returns a promise for `{ value, done }`, and the terminating read has `done: true` with `value` undefined — a loop that reads `value` before checking `done` is a bug. ## Chunks are bytes, and they are not messages Two independent mistakes live here. First, **chunk boundaries are arbitrary**. They are decided by network packetisation, decompression and the browser's own buffering, not by the server's writes. You may get one chunk for a whole response, or a chunk that ends halfway through a line. Never assume one chunk equals one record. Keep a buffer, append each decoded chunk, split on your delimiter, and carry the trailing fragment forward: ```js let buffer = ''; buffer += text; const parts = buffer.split('\n'); buffer = parts.pop(); // last element may be a partial line ``` Second, **a chunk is bytes, not characters**. UTF-8 encodes most non-ASCII characters in two to four bytes. If a chunk boundary falls between the two bytes of `é`, then `new TextDecoder().decode(chunk)` on each chunk independently decodes each half to U+FFFD, the replacement character, and the text is quietly corrupted. Nothing throws; you just get `��` in the output. ## The streaming decoder The platform gives you two forms of the fix. The stream form is a transform: ```js const textStream = res.body.pipeThrough(new TextDecoderStream()); const reader = textStream.getReader(); // value is now a string ``` `pipeThrough` takes a `TransformStream`, pipes the stream into its writable side, and returns its readable side — so it also locks the original. `TextDecoderStream` keeps decoder state across chunks: a trailing incomplete character is buffered and emitted once the bytes that finish it arrive. The manual form is the same state, held by hand: ```js const decoder = new TextDecoder(); // utf-8 by default text += decoder.decode(value, { stream: true }); // hold back partials // after the loop, flush anything left: text += decoder.decode(); ``` Because `pipeThrough` accepts any `TransformStream`, you can build a pipeline: decompress, decode, then a transform of your own that emits whole lines, so the read loop deals only in records. ## Async iteration Some engines let you write `for await (const chunk of res.body)`, which is much nicer than the reader loop. Support has been uneven — Safari in particular lacked it long after Chrome and Firefox shipped it — so `getReader()` remains the portable form unless you have verified your targets. ## When not to stream If the endpoint returns a modest JSON document that you are going to parse in one go anyway, streaming buys nothing and costs you framing code, error handling and tests. Stream when time-to-first-render matters, when the payload is large enough that buffering it is a memory problem, or when the response is genuinely an open-ended sequence of records.