Loading...
Spaceplay← →stepRreset
See how React concurrent rendering works with an interactive visualization. Watch a transition render at low priority, an urgent input interrupt it, React discard the stale work and restart, and the final commit land without blocking typing.
Loading visualization...
Concurrent rendering lets React prepare a new tree in small interruptible chunks, so urgent updates like typing can cut in front of slow ones, and half-finished work can be thrown away without the user ever seeing it.
Before React 18, every state update produced one synchronous render: React called your components from the root down and did not return control to the browser until the whole tree was built and committed. A slow render of a large list meant dropped frames, and a keystroke that arrived during it waited until the render finished. Concurrent rendering changes the shape of that work without changing what your components look like.
The core idea is priority. Every update is stamped with a lane, one bit in a 31-bit mask defined in ReactFiberLane. A state update inside a click or keypress gets SyncLane. An update wrapped in startTransition, or the catch-up render scheduled by useDeferredValue, gets a TransitionLane. When React decides what to render next it picks the highest priority pending lane, and it renders only the updates that belong to that lane, leaving lower priority updates queued for a later pass.
Transition lanes are rendered by workLoopConcurrent, which processes one fiber at a time and asks the Scheduler package whether it should yield. The Scheduler answers yes roughly every 5 ms. React then exits the loop and posts a MessageChannel message to resume, which gives the browser a chance to paint and dispatch events. If a higher priority update arrives during one of those gaps, React abandons the work-in-progress tree and starts again with the new state.
Throwing work away is safe because the render phase is pure: it only builds fibers in memory and never touches the DOM or runs effects. The commit phase, which does touch the DOM, is still synchronous and cannot be interrupted, so the screen never shows a partially applied update. Concurrent behaviour is opted into per update through startTransition, useTransition, and useDeferredValue. Plain setState calls in event handlers are still rendered synchronously, exactly as before.
Interview framing: define Concurrent Rendering in one sentence, then explain one concrete runtime behavior and one common pitfall with a short code example.
If setQuery for a controlled input is placed inside startTransition, the input's value is rendered at low priority and can lag behind the user's typing, which is the opposite of the intended effect.
Fix: Keep the state that drives the input urgent, and put only the expensive derived state, such as the filter that renders a large list, inside the transition. Alternatively read the list from useDeferredValue(query).
A transition still does the same amount of work; it only splits it into interruptible slices and lets urgent updates go first. Total render time stays the same or grows slightly because of the yields.
Fix: Use transitions to keep the UI responsive, and use memoization, virtualization, or smaller components to make the render itself cheaper.
Concurrent React may call a component several times before committing, and may discard a render entirely. Code that mutates a ref, writes to a global, or logs analytics during render will run an unpredictable number of times.
Fix: Keep render pure. Move side effects into useEffect or event handlers, and treat StrictMode's double render as a test for this property.
The transition flag is only set for the synchronous duration of the callback. A setState that runs after an await inside the callback is scheduled with the default lane, not a transition lane, and does not get transition semantics.
Fix: Call the state setter synchronously inside the callback, or wrap the specific setter call after the await in its own startTransition.
Common interview prompts with concise model answers.
A lane is a priority level represented as a single bit in a 31-bit integer. Bitmasks let React store many pending priorities on one root, test for the highest one with a cheap bit operation, and merge several updates into one render by OR-ing their lanes together. SyncLane is the lowest set bit and therefore the highest priority.
The concurrent work loop checks shouldYield between fibers and returns to the Scheduler about every 5 ms. If a higher priority lane appears, React discards the work-in-progress tree and restarts. This is safe because the render phase only builds fibers in memory; nothing is written to the DOM until the synchronous commit phase, so no partial state is ever visible.
function workLoopConcurrent() {
// Process fibers until the Scheduler asks us to yield
while (workInProgress !== null && !shouldYield()) {
performUnitOfWork(workInProgress);
}
}startTransition marks specific state updates as low priority at the point where they are dispatched, and useTransition adds an isPending flag. useDeferredValue works on a value instead: during an urgent render it returns the previous value and schedules a transition-priority re-render with the new one. Use startTransition when you own the setter, and useDeferredValue when the value comes from props or a parent you cannot change.
// Owning the setter
const [isPending, startTransition] = useTransition();
startTransition(() => setFilter(value));
// Receiving the value from a parent
const deferredQuery = useDeferredValue(query);
<Results query={deferredQuery} />When a transition render suspends, React treats replacing already visible content with a fallback as a worse outcome than waiting. It leaves the current tree committed, marks the root as suspended, and retries the render when the promise resolves. A sync update that suspends has no such option and commits the nearest fallback, which is why data fetching triggered by user input is usually wrapped in a transition.
No. With createRoot every app has the concurrent renderer, but individual updates still default to synchronous behaviour. Only updates marked through startTransition, useTransition, useDeferredValue, or a suspending Suspense boundary render in interruptible slices. This per-update design lets a codebase adopt concurrency one hot path at a time.
Continue with these concepts to strengthen your mental model.
function Search({ items }) { const [query, setQuery] = useState(""); const filtered = items.filter((item) => item.name.includes(query) ); return ( <> <input value={query} onChange={(e) => setQuery(e.target.value)} /> <List items={filtered} /> {/* 5,000 rows */} </> );}no pending updates
waiting
waiting
waiting