DEV Community: Maaz Bin Tariq

Smoothing streamed LLM text in React: it looks like a typewriter loop. It isn't.

Maaz Bin Tariq — Fri, 26 Jun 2026 03:38:21 +0000

Smoothing streamed LLM text in React: it looks like a typewriter loop. It isn't.

When a model streams a reply, the text doesn't arrive one character at a time. It arrives in clumps — a couple of words, a pause, then a whole sentence at once. Render each clump as it lands and the output stutters: text jumps, stalls, jumps again. The chat apps you actually like to use hide this. The words glide in at a steady, readable pace, and that smoothness is faked on top of bursty data.

Faking it looks like a five-line typewriter loop. It isn't — at least not if you want it correct across languages, honest about latency, and free of a flash that only shows up when a user hits "regenerate."

The snippets below are distilled from use-smooth-text, a small zero-dependency hook I put on npm. The production code is a little more careful than what's here, but these are the same ideas.

Before the traps: why the browser, not the server

The popular way to get this is the Vercel AI SDK's smoothStream. It works well, with one catch that's easy to miss: it's a server-side transform, and that server has to be JavaScript. It re-chunks the model's output as it passes through your Node process before it reaches the browser.

Many LLM backends aren't Node. They're Python, Go, Rust, or something behind a gateway. If that's you, smoothStream isn't available — the code path doesn't exist on your side.

But smoothing is a rendering concern, not a transport one. By the time text reaches the browser it's just a string, and a string is a string whether it came from FastAPI over SSE or a Node server over a WebSocket. So do the smoothing in the browser, on whatever text has arrived so far. That one decision makes it backend-agnostic — and it's the whole reason the hook is controlled by a plain string you already have:

const { text } = useSmoothText(full, { done })
return <p>{text}</p>

You keep appending chunks to full however you received them. The hook hands back a smoothly-growing slice of it. It never knows your backend exists.

Now the three traps.

Trap 1: "one character at a time" is a lie in most of the world

The obvious reveal is full.slice(0, n), incrementing n. That indexes by UTF-16 code unit, and plenty of characters are more than one code unit. A 👍 is two. A 👨‍👩‍👧 family emoji is many, glued together with zero-width joiners. Slice through the middle and you render half a surrogate pair — a broken-glyph "tofu" box — for one frame, every time one passes.

It's worse for whole writing systems. "Reveal a word at a time" by splitting on spaces does nothing useful for Chinese or Japanese, and stepping by code unit mangles combining marks in Arabic and Hebrew.

The browser already knows where the real boundaries are. Intl.Segmenter gives you graphemes (or words, locale-aware) so you only ever cut where a human would:

const seg = new Intl.Segmenter(undefined, { granularity: 'grapheme' })
// boundaries: the character offsets you're allowed to cut at
const boundaries = [0]
for (const { index, segment } of seg.segment(full)) {
  boundaries.push(index + segment.length)
}

Reveal up to the largest boundary that's ≤ where you're "supposed" to be, and a half-emoji never reaches the screen.

Trap 2: a fixed speed is either too slow or a lie

The typewriter loop reveals one unit every N milliseconds. Pick a speed and you've picked a problem.

Too slow, and you fall behind a fast model and stay behind — the user finishes reading, the buffer's still draining, the text crawls long after the answer arrived. Too fast, and you're back to rendering the bursts you were trying to smooth out.

The fix is to make the speed depend on how far behind you are. Reveal at a base rate normally, but when a big chunk lands and the backlog grows, speed up enough to clear it within a short window:

const remaining = arrivedChars - revealedChars
const charsPerSec = Math.max(baseRate, remaining / CATCH_UP_SECONDS)

Now it glides during the quiet stretches and accelerates through bursts, landing roughly when the stream does instead of lagging forever.

This is also where the tradeoff becomes visible to users. Smoothing trades a little immediacy for a steadier read. If you under-set the base rate, that trade shows — the smoothed text finishes noticeably after the raw stream, and it looks slower rather than nicer. Set the base rate near your model's actual token throughput and the delay becomes imperceptible; it evens out the cadence rather than adding to it. The knob is there because the right value depends on your model, not because there's a free lunch.

Trap 3: the flash I almost shipped

This one didn't show up in the demo, the tests, or local clicking around. I caught it by accident while testing the regenerate flow: the message gets replaced with a completely different reply, and for a single frame the new text flashed at the wrong length before it corrected itself.

The displayed text is full.slice(0, revealedChars). When full is swapped for new, unrelated text, revealedChars is still the count from the old message. So for one frame you render newText.slice(0, oldCount) — a chunk of the new reply, at the wrong length — before anything corrects it.

My first instinct was to reset revealedChars to 0 in an effect when the text changes. That's too late: effects run after the browser paints, so the wrong frame is already on screen. The actual fix is to do the reset during render, using React's "adjust state during render" pattern, so React re-renders with the corrected value before it ever paints:

// during render, not in an effect
if (prevText !== full) {
  setPrevText(full)               // always track the latest text
  if (isReset(prevText, full)) {
    setRevealedChars(0)           // only on a real reset — corrected before paint, no flash
  }
}

isReset here is just "the new text isn't an extension of the old one" — a normal streamed append ("hel" → "hello") isn't a reset; a regenerate is. The lesson that stuck: when you fix derived state matters as much as whether you fix it. An effect was the intuitive place and the wrong one.

What it deliberately doesn't do

It smooths the visual reveal, not the network. It can't make a slow server fast — but doing it in the browser is exactly what makes it work everywhere.
Feed it human-readable text, not tool-call or JSON payloads. You don't want to type out a function-call argument one character at a time.
It's append-only. It expects the string to grow; a non-prefix change is treated as a new message (see trap 3), not an edit of what's already shown.
It doesn't parse markdown. For streaming markdown, pair it with a renderer that completes partial syntax; revealing by word instead of character also cuts down on mid-token flicker.

Try it

npm install use-smooth-text

There's a side-by-side demo in the repo that's easier to judge than a GIF — and the package is about 1 kB min+gzip with zero runtime dependencies.

The whole thing started as "this is just a setInterval." It mostly isn't — the interesting parts are the boundaries you're allowed to cut on, the speed you reveal at, and the single frame between a render and an effect.

Form drafts that survive a closed tab — and the 5 bugs everyone ships first

Maaz Bin Tariq — Mon, 22 Jun 2026 16:19:36 +0000

Saving React form drafts to localStorage: five failure modes, three from one mistake

A user fills out a long form, the tab closes, and the work is gone. The fix looks like two useEffects. It isn't.

A naive "persist to localStorage" hook breaks in five distinct ways, and most of them never show up in the demo, the code review, or local testing. Three of the five aren't separate bugs at all — they're the same mistake showing up in three places.

The snippets below are distilled from use-form-draft, a small hook I wrote and put on npm. It's the worked example; the simplified versions here are easier to read than the production code, but they're the same ideas.

The five failure modes:

The empty initial state overwrites a saved draft on first paint.
React 18 StrictMode double-mounts and writes anyway.
React Hook Form re-renders write to storage on every render.
Accessing localStorage throws and takes the form down with it.
A draft from an old schema corrupts the new form, or crash-loops it.

The first three share a single cause. The last two each need their own guard.

The naive version

useEffect(() => {
  localStorage.setItem(key, JSON.stringify(form));
}, [form]);

useEffect(() => {
  const saved = localStorage.getItem(key);
  if (saved) setForm(JSON.parse(saved));
}, []);

It looks right, and it works when you test it by hand. It breaks in the situations you don't hit locally.

Failure modes 1–3 share one cause

1. The empty state overwrites the draft on first paint. Effects run in the order they're declared, so the write effect goes first: it serializes the empty initial form straight over yesterday's saved draft. The restore effect runs immediately after and reads back the empty value that was just written. The draft is gone, and nothing brings it back.

2. StrictMode writes anyway. In development, React 18 StrictMode mounts, unmounts, and remounts to surface side-effect bugs. The usual patch for failure 1 (a mountedRef that skips the first run) fails here: the ref survives the remount and already reads true on the second mount. The guard lets the write through and clobbers the draft.

3. React Hook Form thrashes storage. form.watch() returns a new object reference on every render. A naive [values] dependency then fires a synchronous setItem on every keystroke and on every unrelated re-render up the tree. It works, but it writes far more than it should.

All three write because a render happened, not because the data changed. So compare the data. Keep the last thing you serialized, and write only when the new serialization differs:

// Seed with the initial serialized state, so the first run sees "no change"
// and writes nothing. This also covers StrictMode's double mount.
const lastWritten = useRef(JSON.stringify(state));

useEffect(() => {
  const json = JSON.stringify(state);
  if (json === lastWritten.current) return; // data didn't change → no write
  lastWritten.current = json;
  localStorage.setItem(key, json);
}, [state]);

That one comparison closes all three holes. The empty initial state matches the seed, so first paint writes nothing. StrictMode's second mount matches it too. And React Hook Form's fresh-but-identical object serializes to the same string, so none of those re-renders write. Only a real edit produces a different string.

Two caveats, since this leans on JSON.stringify as a content hash. It assumes the state is JSON-serializable with stable key order. For plain, string-keyed form objects that usually holds, though engines order integer-like keys numerically regardless of insertion, so avoid numeric field names. The bigger gap is values that don't round-trip: Map and Set both serialize to {}, undefined fields drop out, and NaN/Infinity become null. Any of those can make two different states hash the same and skip a write, so hash a normalized shape if your form holds them.

The full version in the package adds a debounce, strips excluded fields (passwords, card numbers) before hashing, and wraps the JSON.stringify itself, but the load-bearing idea is that one comparison.

Failure 4: accessing `localStorage` can throw

This one never reproduces on your machine, because your machine is fine.

Touching localStorage can throw, and not only when you write to it. A full quota or old Safari's private mode throws on the setItem. A sandboxed iframe, or a "block site data" policy, throws on the property access itself (window.localStorage) before any method runs, and typeof doesn't suppress that. (Modern Safari, Firefox, and Chrome private/incognito modes are fine: they give you a working, smaller-quota store and stopped throwing on normal writes years ago.)

Because all of this sits on the render path, an exception doesn't stay contained — it can take down the whole form the helper was meant to protect. So both the access and every method have to degrade to a quiet no-op:

function getStore(): Storage | null {
  try {
    return window.localStorage; // the access can throw, so guard it too
  } catch {
    return null;
  }
}

function safeSet(store: Storage | null, key: string, value: string) {
  if (!store) return;
  try {
    store.setItem(key, value);
  } catch {
    // quota full, disabled by policy, old Safari private mode.
    // a dropped draft is fine; crashing the form isn't.
  }
}

function safeRemove(store: Storage | null, key: string) {
  if (!store) return;
  try {
    store.removeItem(key);
  } catch {
    /* ignore */
  }
}

The same wrapping goes around getItem and JSON.stringify too (the latter throws on a BigInt or a circular reference). Persistence here is best-effort: a failed write just means there's no saved draft, which the user can live with. It never gets to throw into the form.

Failure 5: a stale draft corrupts the new schema

Forms change shape. You ship v2 where title goes from a string to { en, ar }, and a user still has a v1 draft in storage. You hydrate it, and last month's data pours into this month's inputs. Usually that just renders garbage — a blank field, a wrong value. Sometimes it throws, and if it throws unhandled, the broken draft stays in storage and crash-loops the form on every remount, so a refresh can't even rescue the user.

Two cheap guards handle it. Stamp a schema version on every draft and discard mismatches on read, and delete any draft whose hydrate throws.

type Draft<T> = { version: number; savedAt: string; state: T };

function read<T>(store: Storage | null, key: string, version: number): Draft<T> | null {
  if (!store) return null;
  try {
    const raw = store.getItem(key);
    if (!raw) return null;
    const draft = JSON.parse(raw) as Draft<T>;
    if (draft.version !== version) return null; // shape changed → discard
    return draft;
  } catch {
    return null; // corrupted JSON → discard
  }
}

// on mount:
const draft = read<FormShape>(store, key, SCHEMA_VERSION);
if (draft) {
  try {
    hydrate(draft.state);
  } catch {
    safeRemove(store, key); // one poisoned record can't break every visit
  }
}

Bump SCHEMA_VERSION on any incompatible change and old drafts get dropped on read instead of breaking the form. The same savedAt field also drives an expiry check and a "restored 3 minutes ago" label.

The tests are the proof

These are easy to fix once you know they exist. The catch is that all five are invisible until production, so they need tests that pin the behaviour rather than code that happens to work today. Each failure mode in the package is one named, runnable regression test: no write on the StrictMode double mount, no write on an identical-content re-render, a no-op when storage throws (including the property-access throw), a discarded draft on version mismatch, a deleted draft when hydrate throws. There's an SSR test too, for the server-render path.

When you might not need a library

If you only use React Hook Form and want no recovery UI, a smaller RHF-specific package will weigh less. If you want autosave to a server, this whole category is the wrong tool. And if your form state is plain and you just want the behaviour, the guard from the first section is most of the job — copy it.

But if you want the rest of it handled — the storage-throw guards, schema versioning, a debounce, a recovery banner, and adapters for React Hook Form, Formik, and TanStack Form — that's what use-form-draft packages. Either way, the test file is the fastest way to see each of these five bugs reproduced and fixed.

DEV Community: Maaz Bin Tariq

Smoothing streamed LLM text in React: it looks like a typewriter loop. It isn't.

Smoothing streamed LLM text in React: it looks like a typewriter loop. It isn't.

Before the traps: why the browser, not the server

Trap 1: "one character at a time" is a lie in most of the world

Trap 2: a fixed speed is either too slow or a lie

Trap 3: the flash I almost shipped

What it deliberately doesn't do

Try it

Form drafts that survive a closed tab — and the 5 bugs everyone ships first

Saving React form drafts to localStorage: five failure modes, three from one mistake

The naive version

Failure modes 1–3 share one cause

Failure 4: accessing localStorage can throw

Failure 5: a stale draft corrupts the new schema

The tests are the proof

When you might not need a library

Failure 4: accessing `localStorage` can throw