Transitions and deferred values

useTransition splits one event into two updates: an urgent one that renders immediately, and a non-urgent one React can interrupt. You call setQuery urgently so the input reflects the keystroke at once, then call the expensive setResults inside startTransition. React renders the urgent update first; the transition render happens in the background and can be thrown away if another keystroke arrives, so it never blocks input.

const [isPending, startTransition] = useTransition();
const [query, setQuery] = useState("");
const [results, setResults] = useState<Row[]>(allRows);

function onChange(e: React.ChangeEvent<HTMLInputElement>) {
  const next = e.target.value;
  setQuery(next); // urgent: the input must update now
  startTransition(() => {
    setResults(filterRows(allRows, next)); // non-urgent: can lag, can be dropped
  });
}

isPending is true while a transition render is in flight — use it to dim the stale list, never to block typing.

useDeferredValue is the same idea when you don’t own the setter — you defer a value, not an update. A child receives query as a prop and does the expensive work itself; you can’t wrap that child’s internal render in startTransition. Instead, hand it a deferred copy of the value. React keeps the input bound to the live query, but lets the deferred copy lag during heavy renders.

const [query, setQuery] = useState("");
const deferredQuery = useDeferredValue(query);
const isStale = query !== deferredQuery;

return (
  <>
    <input value={query} onChange={(e) => setQuery(e.target.value)} />
    {/* SlowList re-renders against deferredQuery, lagging behind input */}
    <SlowList query={deferredQuery} dim={isStale} />
  </>
);

Rule of thumb: own the setter at the call site → useTransition. Receive the value as a prop you can’t intercept → useDeferredValue. Memoize the expensive child (memo) so the deferred lag actually saves renders.

Under Suspense, a transition tells React to keep showing the previous content instead of dropping to a fallback. When the deferred update reads data that suspends, a normal update would unmount the old UI and show the <Suspense> fallback — the list blinks to a skeleton on every keystroke. Wrapping the update in a transition (or letting useDeferredValue drive it) makes React hold the last good content on screen and swap in the new results only when they’re ready. You get stale-while-loading for free.

function Search() {
  const [query, setQuery] = useState("");
  const deferredQuery = useDeferredValue(query);
  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <Suspense fallback={<ResultsSkeleton />}>
        {/* first paint shows the skeleton; later keystrokes keep the
            previous results visible instead of re-blinking to skeleton */}
        <Results query={deferredQuery} />
      </Suspense>
    </>
  );
}

The skeleton shows once, on the first load. After that, transitions turn every subsequent fetch into a soft content swap, not a flash.

The failure mode that defines the pattern: never wrap the urgent update in a transition, and never reach for either API before measuring. If you put setQuery inside startTransition, the input value itself becomes interruptible — typing lags, the exact symptom you were trying to cure. The urgent update (what the user is directly manipulating) must stay outside. The second failure is premature: a list of 50 rows re-renders in under a millisecond; adding useTransition/useDeferredValue there buys nothing and adds a stale-state concept to reason about. These APIs pay off only when an expensive render is measurably starving an urgent one.

// WRONG: the input value is urgent — this makes typing laggy
startTransition(() => {
  setQuery(next);          // urgent update demoted to non-urgent
  setResults(filterRows(allRows, next));
});

// RIGHT: urgent stays urgent, only the expensive part is deferred
setQuery(next);
startTransition(() => setResults(filterRows(allRows, next)));

Reach for transitions when you’ve seen input lag under heavy updates — not as a default wrapper around every setState.