Concurrent Rendering and Automatic Batching
React 19 introduces a cooperative scheduling model for concurrent rendering, allowing rendering tasks to be paused, resumed, or restarted based on their urgency. Urgent updates, such as user inputs, are prioritized, while non-urgent tasks are processed later. Automatic batching consolidates updates from various sources into fewer render cycles, enhancing responsiveness. This concurrency model emphasizes the importance of architectural boundaries, as poor design can lead to inefficiencies. Best practices include keeping input updates urgent, deferring only necessary updates, and stabilizing component boundaries to optimize performance and maintain a responsive user interface.
We'll cover the following...
- Concurrency as a scheduling model
- Urgent, transition, and deferred work
- Automatic batching
- Concurrency and architectural boundaries in React
- Example: Layered concurrency and async batching
- The priority waterfall
- Advanced optimization: Costs of concurrency in React
- Best practices
- Practice exercises
- Exercise: Demonstrating automatic batching across async boundaries
React 19’s concurrency is built on a cooperative scheduling model. Rendering is speculative and can pause, resume, or restart, while commits remain atomic. The scheduler merges updates from multiple sources, and automatic batching helps maintain a responsive interface even under heavy workloads. This lesson walks through how the scheduler processes concurrent rendering work.
Concurrency as a scheduling model
React doesn’t make slow code faster. It changes when work runs. Every state update enters React’s scheduler with a priority. Urgent updates, such as user input, are handled immediately, while non-urgent tasks, like heavy recalculations, list filtering, or route transitions, are processed at a lower priority. React may start rendering a low-priority update, pause midway for a high-priority interaction, and resume the original work later. This is achieved through time slicing, where render work is split into small windows (~5ms) and React yields to the main thread between windows to check for urgent tasks.
This behavior relies on the Fiber architecture: the component tree is rendered incrementally, node by node. If urgent work arrives, React discards partial renders and restarts with the higher-priority update. That’s why rendering is speculative while committing is definitive. The combination of interruptibility and prioritization is what gives React its concurrent behavior. That concurrency is fully cooperative rather than parallel.
Urgent, transition, and deferred work
In advanced applications, multiple update types compete for the main thread:
Urgent updates: These must be reflected immediately: input state, cursor position, toggles, and imperative UI changes. React executes these synchronously (or at high priority in concurrent mode) and commits them as soon as possible.
Transition updates: These represent “non-blocking UI updates.” React starts rendering them concurrently and may restart them many times if urgent work interrupts. Transitions keep the previous UI visible until the speculative render reaches a complete, commit-ready state.
Deferred values: These are downstream updates that adopt a slower, trailing version of some upstream state. They reduce unnecessary propagation of rapid changes and allow transitional work to stabilize before triggering deep renders.
Taken together, these mechanisms form a scheduling hierarchy rather than three independent concepts. Urgent updates preempt transitions. Transitions preempt deferred values. The goal is not parallelism. The goal is to preserve controlled responsiveness under load.
Automatic batching
In React 19, state updates are automatically batched across all sources, not just React event handlers. This includes updates from: