React 18 Concurrent Rendering Explained

Understanding React 18 Concurrent Rendering React 18 fundamentally re-architects how updates are processed, moving away from a blocking, synchronous model…

Understanding React 18 Concurrent Rendering

React 18 fundamentally re-architects how updates are processed, moving away from a blocking, synchronous model to an interruptible, concurrent one. This paradigm shift, centered around concurrent rendering, allows React to prepare multiple versions of the UI simultaneously and pause, resume, or even abandon rendering work based on priority. The primary goal is to keep the application responsive by ensuring urgent updates, like user input, are handled immediately without being blocked by less urgent, computationally intensive rendering tasks.

The Problem: Blocking Renders in Synchronous React

Prior to React 18, all rendering work was synchronous and atomic. Once React started rendering an update, it would not yield control back to the browser until the entire update was committed to the DOM. This "all or nothing" approach led to several responsiveness issues:

  • Input Lag: A large, complex state update triggered by an input change could block the main thread, making the UI feel sluggish and unresponsive to subsequent keystrokes or clicks.
  • Janky Animations: If an animation frame coincided with a heavy rendering task, the animation could stutter or freeze.
  • Stale UI: Users might see a partially rendered or outdated UI while a background data fetch completed and triggered a large update.

Developers often resorted to manual debouncing, throttling, or setTimeout(..., 0) hacks to mitigate these issues, introducing complexity and potential for subtle bugs.

The Solution: Concurrent Rendering and Prioritization

React 18's concurrent renderer can interrupt, pause, and resume rendering work. It achieves this by working with a priority system and integrating with the browser's scheduling mechanisms (like requestIdleCallback and MessageChannel, though it uses its own scheduler for more fine-grained control). Instead of rendering directly to the DOM, React 18 renders to an off-screen buffer or "fiber tree" which can be discarded if a higher-priority update comes in.

Key concepts involved:

  • Render Interruption: React can pause a low-priority render to handle a high-priority event (e.g., keyboard input), then resume or restart the low-priority render later.
  • Time Slicing: Rendering work is broken down into small, interruptible units. React can check for higher-priority events after each unit.
  • Batching: React groups multiple state updates into a single re-render for performance. In concurrent mode, this batching is more aggressive and automatic, even for updates outside of event handlers (e.g., promises, setTimeout).
  • Transitions: A new concept to mark updates as "non-urgent" so React knows it can defer their rendering.

Explicit Opt-in for Concurrency: startTransition

While React 18 enables concurrent features under the hood, developers explicitly indicate which updates can be treated as non-urgent using the startTransition API. This is crucial for distinguishing between user-initiated, high-priority interactions and background, lower-priority data fetching or UI updates.

The startTransition function marks all state updates scheduled inside its callback as "transitions." Transitions are interruptible and will yield to urgent updates (like typing into an input field). If an urgent update occurs while a transition is in progress, React will discard the incomplete transition render and prioritize the urgent update.

import { startTransition, useState } from 'react';

function SearchBar() {
  const [inputValue, setInputValue] = useState('');
  const [searchQuery, setSearchQuery] = useState('');

  const handleInputChange = (event) => {
    // Urgent update: update the input field immediately
    setInputValue(event.target.value);

    // Non-urgent update: start a transition for the search query
    startTransition(() => {
      setSearchQuery(event.target.value);
    });
  };

  return (
    <div>
      <input type="text" value={inputValue} onChange={handleInputChange} placeholder="Search..." />
      <p>Displaying results for: {searchQuery}</p>
      {/* SearchResults component would render based on searchQuery */}
    </div>
  );
}

In this example, typing into the input field triggers two updates: setInputValue and setSearchQuery. setInputValue is a standard, urgent update that makes the input responsive. setSearchQuery is wrapped in startTransition, making it a non-urgent transition. If the user types rapidly, the setSearchQuery update might be interrupted or delayed, ensuring the input field remains smooth.

useDeferredValue for UI Responsiveness

useDeferredValue is another hook for deferring updates to a value, similar in concept to debouncing but integrated into React's concurrent scheduler. It takes a value and returns a "deferred" version of it. The deferred value will only update after React has finished processing urgent updates.

import { useDeferredValue, useState } from 'react';

function SearchResults({ query }) {
  // Assume this component performs a heavy search or renders many items
  // based on the query prop.
  return <div>Displaying search results for: <strong>{query}</strong></div>;
}

function ParentComponent() {
  const [inputValue, setInputValue] = useState('');
  // Defer the query value used by SearchResults
  const deferredQuery = useDeferredValue(inputValue);

  const handleInputChange = (event) => {
    setInputValue(event.target.value);
  };

  return (
    <div>
      <input type="text" value={inputValue} onChange={handleInputChange} placeholder="Search..." />
      <SearchResults query={deferredQuery} />
      <p>(Input value: {inputValue})</p>
    </div>
  );
}

Here, inputValue updates immediately, keeping the text field responsive. deferredQuery, however, only updates when React has "idle" time, allowing the potentially expensive SearchResults component to render without blocking user input. This gives a similar effect to startTransition but is applied to a specific value rather than an update function, making it useful when you need to defer a prop passed down to a child component.

Automatic Batching Enhancements

Prior to React 18, state updates were batched only within browser event handlers. For example:

// React 17 and earlier: Only one re-render
onClick={() => {
  setCount(c => c + 1);
  setFlag(f => !f);
}}

// React 17 and earlier: Two re-renders (one for each setTimeout)
setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
}, 0);

In React 18, automatic batching is enabled by default for all updates, regardless of where they originate (event handlers, promises, setTimeout, etc.). This means that multiple state updates triggered from anywhere will generally be batched into a single render pass, leading to improved performance and fewer unnecessary re-renders.

// React 18: Only one re-render (even inside setTimeout)
setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
}, 0);

If for some reason you need to opt out of automatic batching for specific updates (which is rarely needed), you can use ReactDOM.flushSync(). However, using flushSync can harm performance by forcing React to render synchronously and block the browser, so it should be used with extreme caution and only when absolutely necessary (e.g., measuring DOM nodes right after an update).

StrictMode and Concurrent Features

When running in <StrictMode>, React will intentionally double-invoke effects and run component functions twice in development mode. This helps uncover potential issues with concurrent rendering, specifically related to components being resilient to being mounted/unmounted and state updates being non-idempotent. While StrictMode doesn't enable concurrent rendering itself, it helps ensure your components are compatible with the concurrent model.

Common Pitfalls and Considerations

  • Timing-Sensitive Logic: Code that relies on immediate DOM updates after a state change might behave differently with startTransition or useDeferredValue. If you need to read the DOM immediately after an update, ensure that update is not part of a transition. In rare cases, ReactDOM.flushSync might be necessary, but use it sparingly.
  • Unintended Deferrals: Be mindful of what updates you wrap in startTransition. Wrapping truly urgent updates can lead to a sluggish UI.
  • Race Conditions: When dealing with asynchronous data fetching inside transitions, ensure proper cancellation or cleanup to avoid showing stale data or processing responses for discarded renders. useTransition (the hook version of startTransition) provides an isPending flag to show loading indicators, helping manage user expectations during deferred operations.
  • Server-Side Rendering (SSR): React 18 also brings enhancements to SSR with streaming HTML and selective hydration, which complement concurrent rendering. Understanding how these work together is important for full-stack React applications.
  • Third-Party Libraries: Most well-maintained libraries are compatible with React 18. However, older libraries or those that deeply interact with React's internals might need updates to fully support concurrent features. Pay attention to warnings in the console during development.

Back to the knowledge base · Ask the AI assistant