Frontend Beauty
ESC

Type to search the knowledge base.

useDeferredValue

useDeferredValue lags a value behind urgent state so heavy children render with lower priority without dual setState.

advanced3 min read
  • react
  • usedeferredvalue

When one piece of state drives both a snappy control and a heavy subtree, useDeferredValue gives you a lagging copy of that value. React updates the deferred value at transition priority so the control can stay current.

Docs: useDeferredValue.

Pattern

function Catalog({ products }) {
  const [filter, setFilter] = useState('');
  const deferredFilter = useDeferredValue(filter);
  const isStale = filter !== deferredFilter;

  const visible = useMemo(
    () => products.filter((p) => p.name.includes(deferredFilter)),
    [products, deferredFilter]
  );

  return (
    <>
      <input
        value={filter}
        onChange={(e) => setFilter(e.target.value)}
        aria-label="Filter products"
      />
      <div style={{ opacity: isStale ? 0.7 : 1 }}>
        <ProductGrid items={visible} />
      </div>
    </>
  );
}

The input binds to filter (urgent). The grid uses deferredFilter. Stale UI can dim via opacity while catching up — optional but good UX feedback.

Versus useTransition

API You control
useTransition Which setState calls are non-urgent
useDeferredValue Which derived reads may lag

If you already have a single state variable, deferred value is often fewer moving parts than splitting into two states + transition.

Memo still matters

Deferring the value does not magically skip work if a child re-renders from a parent for other reasons. Combine with memo on heavy pure children when profiling says so.

Interview out-loud

“useDeferredValue returns a lagging version of a value so urgent UI can use the fresh state while expensive children render with the deferred one. I compare filter !== deferredFilter for pending styling. It is the value-oriented sibling of useTransition.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides