Priority lanes, time-slicing, and useTransition

You wrap a slow list filter in startTransition. Typing stays instant, the list catches up when React has spare time, and a spinner signals the wait. Without it, every keystroke triggers a 50 ms blocking render. The mechanism that makes this work is React’s priority lane system.

Priority lanes. React 18 assigns every update a lane — a priority bucket. The lane model (a bitmask of 31 lanes) lets React work on high-priority updates first and defer low-priority ones. The important tiers:

• Sync / discrete: A click, a keypress. React renders it immediately and blocking, because the user is waiting on that exact interaction.
• Default: Ordinary state updates with no transition wrapper.
• Transition: Set via useTransition or useDeferredValue. Used for updates the user is not directly waiting on — filtering a big list, navigating to a new view. These can be interrupted by anything more urgent.
• Idle: The lowest. Background work the app can do whenever the main thread is free.

When a keypress arrives mid-transition-render, React abandons the in-progress transition render, processes the keypress at high priority, and restarts the transition afterward.

Time-slicing: how the render phase yields. A long synchronous render blocks input — the exact failure mode the event-loop piece described. React’s scheduler breaks the render phase into slices. After about 5 ms of reconciliation work, the scheduler checks shouldYield(); if true, it stops, posts a continuation task via MessageChannel (the cross-browser way to schedule a task with no clamping), and lets the browser run input handlers and rendering. The continuation task resumes the render from the stored fiber pointer.

A 50 ms render becomes ten 5 ms slices interleaved with the browser’s own work, and input stays responsive throughout. This only applies to concurrent renders — transitions and other non-urgent updates. A synchronous-priority update (discrete input) still renders in one blocking pass, because making the user wait for a yield would defeat the purpose.

The lane bitmask. A lane is one bit in a 31-bit integer. Representing priority as a bitmask lets React do set operations in single CPU instructions: “are there any high-priority lanes pending?” is a mask-and-test; “render all lanes at or above this priority” is a bitmask comparison. Updates in compatible lanes are batched — multiple setState calls in one event handler (or, since React 18, across promises and timeouts via automatic batching) collapse into a single render. This is why you cannot read the new state synchronously right after setState: the render that applies it has not happened yet.

useTransition and useDeferredValue. These are the two hooks that put work into the transition lane. useTransition gives you a startTransition function — state updates inside it are marked low-priority and interruptible, plus an isPending flag for showing a spinner. The canonical use: a search input where the input value itself updates synchronously (so typing feels instant) but the expensive filtered-list update is wrapped in startTransition (so it yields to further keystrokes).

useDeferredValue is the same idea from the consuming side: it gives you a copy of a value that “lags behind” — React updates it at transition priority, so a component reading the deferred value re-renders only when React has spare time. Use useTransition when you own the state update; useDeferredValue when the value comes from props or context you do not control.