React's Concurrent Rendering: Interruptible UI Updates

Why it exists

Before React 18, rendering was a synchronous, blocking operation. A large component update could freeze the entire application, making it unresponsive to user input like clicks or typing. This created a poor user experience in complex apps. Concurrent Rendering was introduced to solve this by making rendering interruptible.

The mental model

Think of traditional rendering as a single, uninterruptible phone call. Once it starts, you can't do anything else until it's finished. Concurrent Rendering is like having call waiting; React can pause the long, low-priority call (a big data render) to answer a quick, urgent one (user input), and then switch back. It prepares new screens in the background without blocking the main thread.

How it works

Concurrency allows React to start rendering an update, pause in the middle, and continue later, or even abandon it. It achieves this without causing visual glitches by preparing the new UI in memory. It only performs the actual DOM mutations at the very end, once the entire component tree has been evaluated. This guarantees the UI always appears consistent. This process is automatic when you use concurrent features; you don't manage the pausing and resuming yourself.

When to use it

You don't use concurrency directly. Instead, you opt into it by using features built on it. Use startTransition to mark non-urgent updates, allowing React to deprioritize them. Use Suspense for data fetching to show fallback UI while content loads in the background without blocking the rest of the page. These features automatically leverage the concurrent renderer to improve responsiveness.

When not to use it

Since it's an underlying mechanism, the question is less "when not to use it" and more "when is it not active". By default, if you don't use any concurrent features, rendering remains synchronous and blocking, just like in older React versions. It's an opt-in system, so there's no risk of breaking an old app on upgrade unless you start implementing concurrent patterns.

One canonical example

A user types into a search filter for a very long list. Without concurrency, each keystroke would trigger a re-render of the entire list, causing noticeable input lag. With concurrency, you can wrap the list-updating state change in startTransition. Now, React treats the input update as urgent and the list re-render as a non-urgent "transition". It renders the keystroke immediately and handles the list update in the background, interrupting it if the user types again.