Priority lanes, time-slicing, and useTransition

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.

At each yield point the browser gets a turn — that pause is what keeps typing instant during a long render.

The lane bitmask. Why does it matter that lanes are bits rather than strings or numbers? Because the performance of React’s scheduler depends on these operations being single CPU instructions — and understanding this tells you why automatic batching works the way it does. 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.