useDeferredValue

The plain-language idea

useDeferredValue takes a value and gives you back a copy that's allowed to lag behind it. The urgent part of your UI (what you're typing, right now) updates immediately. The expensive part that depends on it (a big filtered list, a heavy chart) re-renders with the deferred copy, on its own schedule, and React is free to interrupt that render if you type again before it finishes.

It's easy to mistake this for a debounce, but there's no timer anywhere. A debounce says "wait 300ms of silence, then run." useDeferredValue says "render the expensive part whenever the browser has a free moment, and if a new update shows up first, throw away the in-progress one and start over." On a fast machine that might mean the deferred render finishes almost instantly; on a slow one it lags more — the behavior adapts to how much spare time there actually is, instead of a number you guessed.

See it in a real thing: a laggy search list

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

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <div style={{ opacity: isStale ? 0.6 : 1 }}>
        <SlowResultsList query={deferredQuery} />
      </div>
    </>
  );
}

const SlowResultsList = React.memo(function SlowResultsList({ query }) {
  const results = expensiveFilter(BIG_LIST, query); // thousands of rows
  return (
    <ul>
      {results.map((r) => (
        <li key={r.id}>{r.label}</li>
      ))}
    </ul>
  );
});

Every keystroke updates query and the <input> immediately — typing never feels laggy. deferredQuery trails behind it, so SlowResultsList re-renders with the previous query while the new, expensive render happens in the background at lower priority. isStale tells you the two have diverged, which is why the list is dimmed until they catch up.

Notice SlowResultsList is wrapped in React.memo. Without it, the component would re-render twice for every keystroke anyway — once eagerly with the old deferredQuery (because its parent re-rendered) and once when the deferred value actually updates — which defeats half the point.

What people usually miss

Watch out

• It doesn't skip work — it deprioritizes it. SlowResultsList still fully re-renders eventually with the latest query. useDeferredValue changes when that render happens relative to more urgent ones, not whether it happens.
• It does nothing useful without memoization on the consumer. If the component reading the deferred value isn't wrapped in React.memo, it re-renders on every parent render anyway, urgent value or not, and the deferral buys you nothing.
• It's not for fetches. useDeferredValue defers a render, not a network request. If SlowResultsList fetches data instead of filtering an in-memory array, this hook has nothing to do with when that fetch fires.
• A debounce and a deferred value solve different problems. Debounce reduces how often something runs (fewer network calls). useDeferredValue changes the priority of a render that still runs every time — it's about responsiveness, not call frequency.

The genealogy: interruptible rendering, not a new idea

This hook only makes sense because React can pause a render partway through and pick it back up — or abandon it — which is exactly the interruptible rendering mechanism covered in the lesson on React's concurrent rendering engine. useDeferredValue is a thin, purpose-built API on top of that same capability, aimed specifically at "let this one subtree lag."