A deep dive into React Fiber

Loading data...

}>

Another key improvement is streaming in server-side rendering (SSR) and selective hydration. Instead of waiting for the server to finish rendering the full page before sending its HTML to the browser, Suspense boundaries allow React to divide the page into independent sections. The server can send an initial HTML shell first and stream the remaining content as it becomes ready.

With selective hydration, Suspense boundaries divide the tree into smaller hydration units. React then hydrates these sections independently, allowing some controls to become interactive while other sections are still waiting for code or data.

Suspense continues to evolve in React 19, particularly in how it schedules sibling work. When a component suspends, React can commit the nearest fallback sooner and then schedule another render to pre-warm lazy resources in the remaining sibling tree. This allows the fallback to appear sooner without preventing other resources from beginning to load.

The Suspense API is nuanced. If you’d like to learn more about it, check out our comprehensive article on Suspense.

What are transitions?

Transitions are one of the main APIs for using concurrent rendering. They let you distinguish between urgent and non-urgent state updates.

Urgent updates include tasks like user inputs or animations where immediate feedback is expected. Non-urgent updates, like rendering a list of search results, are low priority, and slight delays are acceptable.

The transitions API comprises a useTransition hook which allows you to mark state updates as not urgent, as every state update not marked is considered urgent by default.

How do you use useTransition?

The useTransition hook handles transitions between UI states in a non-blocking manner. It returns an array with two values:

• isPending — A boolean indicating if the transition is in progress
• startTransition — A function to start the transition

For example, consider a page with tabs where one tab takes a long time to render:

import { useState, useTransition } from "react";
import About from "./About";
import Posts from "./Posts";

export default function TabContainer() {
  const [activeTab, setActiveTab] = useState("about");
  const [isPending, startTransition] = useTransition();

  function selectTab(nextTab) {
    startTransition(() => {
      setActiveTab(nextTab);
    });
  }
  return (
    <>
       selectTab("about")}> About 
       selectTab("posts")}> Posts 
      {isPending && 
Loading tab...
}
      {activeTab === "about" ?  : }
    >
  );
}

The state update inside startTransition is treated as non-urgent. If the user clicks another button while React is rendering the Posts tab, React can interrupt the first render and handle the new interaction.

Transitions do not delay the function passed to startTransition. React calls that function immediately. Only the state updates scheduled while it runs are marked as transitions.

This means that wrapping an expensive JavaScript calculation in startTransition does not move the calculation into the background:

startTransition(() => {
  // This calculation still runs immediately
  const filteredItems = items.filter(expensiveFilter);
  setFilteredItems(filteredItems);
});

The filter() call still blocks the main thread until it returns. startTransition only changes the priority of the React state update.

What are asynchronous transitions and actions in React 19?

In React 19, functions passed to startTransition are called an Action. An Action can perform asynchronous work, such as a request, while isPending represents the pending interaction.

function SettingsForm() {
  const [settings, setSettings] = useState(initialSettings);
  const [isPending, startTransition] = useTransition();
  function saveSettings(nextSettings) {
    startTransition(async () => {
      const savedSettings = await updateSettings(nextSettings);
      startTransition(() => {
        setSettings(savedSettings);
      });
    });
  }
  return (
     saveSettings({ theme: "dark" })}
    >
      {" "}
      {isPending ? "Saving..." : "Save settings"}{" "}
    
  );
}

State updates that occur after an await currently need another startTransition call to remain transition updates. This is a known limitation caused by React losing the transition context across the asynchronous boundary.

Async transitions connect concurrent rendering with newer React features such as Actions, form Actions, useActionState, and useOptimistic. They allow React to coordinate pending UI, asynchronous work, and the final render as one interaction.

What is useDeferredValue?

The useDeferredValue hook lets one part of the UI update later than another part. It is useful when a value changes urgently, but a component that depends on that value is slow to render.

For example, an input should reflect each keystroke immediately, but a large list of search results can update at a lower priority:

import { Suspense, useDeferredValue, useState } from "react";
export default function SearchPage() {
  const [query, setQuery] = useState("");
  const deferredQuery = useDeferredValue(query);
  const isStale = query !== deferredQuery;
  return (
    <>
      {" "}
       setQuery(event.target.value)}
        placeholder="Search"
      />{" "}
      

        {" "}
        Loading results...}>
          {" "}
          {" "}
        {" "}
      
{" "}
    >
  );
}

In this example, when query changes, React first renders the input with the latest value while deferredQuery keeps its previous value.

React then attempts another render in the background using the latest value. This background render is interruptible. If the user types again before it finishes, React can abandon it and restart with the newest value.

Unlike traditional debouncing, useDeferredValue does not wait for a fixed amount of time. Instead, React attempts the deferred render as soon as it can.

The main difference between useTransition and useDeferredValue is where they are applied.

• Use a transition when you control the state update and can wrap its setter in startTransition.
• Use useDeferredValue when you receive a value through props, a Hook, or another source and want a slower part of the tree to lag behind it.

What is the component in React 19.2?

React 19.2 introduced the component as another feature built on concurrent rendering. Activity lets React hide and restore part of the UI without discarding its internal state.

import { Activity, useState } from "react";
export default function Tabs() {
  const [activeTab, setActiveTab] = useState("home");
  return (
    <>
      {" "}
       setActiveTab("home")}> Home {" "}
       setActiveTab("settings")}> Settings {" "}
      
        {" "}
        {" "}
      {" "}
      
        {" "}
        {" "}
      {" "}
    >
  );
}

When an Activity boundary is visible, React renders it normally and mounts its Effects. When it becomes hidden, React hides its DOM content, cleans up its Effects, and preserves its component and DOM state. Updates to hidden content can still be rendered, but they are scheduled at a lower priority than visible work. When the Activity becomes visible again, React restores the preserved state and recreates its Effects.

Activity clearly demonstrates how Fiber can preserve completed work, lower its priority while it is hidden, and reuse it when it becomes relevant again.

Together, transitions, Suspense, selective hydration, streaming server rendering, Activity, and deferred values expose different aspects of React’s concurrent rendering model.

How does useSyncExternalStore protect external state in concurrent React?

Concurrent rendering introduces an important challenge for state stored outside React. Because React can pause while rendering a component tree, an external store may change during that pause. If different components read different versions of the store, React could produce an inconsistent user interface.

React 18 introduced useSyncExternalStore to give React a reliable way to subscribe to external stores and read a consistent snapshot of their state:

import { useSyncExternalStore } from "react";
function OnlineStatus() {
  const isOnline = useSyncExternalStore(
    subscribe,
    getSnapshot,
    getServerSnapshot,
  );
  return 
{isOnline ? "Online" : "Offline"}
;
}

Here, the first argument subscribes to changes in the external source. The second returns its current value, and the optional third argument provides the value used during server rendering.

useSyncExternalStore is especially useful for state-management libraries and browser APIs whose values can change outside React’s update system.

What is automatic batching?

Automatic batching is a key feature that is the direct result of the underlying changes in React Fiber. It helps to reduce the number of re-renders that happen when a state changes by allowing React to group multiple state updates into a single re-render.

For example, when you call multiple setState functions in a single render cycle, React automatically batches them together into a single update. This can be observed in the code example below:

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    // Multiple state updates within a single event handler
    setCount(count + 1);
    setCount(count + 2); 
  };

  console.log("Rendering")

  return (
    
  );
}

The handleClick function calls setCount twice, once to increment the count by 1 and then again to increment it by 2.

React automatically batches these two state updates into a single update. This means that only one re-render will occur, and “rendering” will only log once in the terminal.

Before the release of React v18, batched updates were performed inside the React event handler. This meant that outside of React’s lifecycle (such as inside a setTimeout or a promise), updates would not be batched automatically. With React Fiber’s improved update in v18, updates are batched across all contexts, including asynchronous code, setTimeout, promises, and native event handlers.

How does the React Compiler optimize code at build time?

The React Compiler complements Fiber by adding build-time memoization that reduces the amount of work Fiber needs to perform at runtime.

Earlier, we saw that a fiber node stores both pendingProps and memoizedProps during reconciliation to decide whether work needs to be done for a fiber.

By comparing pendingProps with memoizedProps, React can determine if the inputs to a component have changed. If they are the same and there are no other updates affecting the fiber, React can skip re-rendering that part of the tree and reuse the previous result. This process is known as memoization.

Memoization happens at runtime after React has already received an update and entered the reconciliation process. Fiber then decides whether part of the tree can be reused.

Hooks such as React.memo, useMemo, and useCallback can help React memoize components, values, or functions where appropriate.

import { memo, useCallback, useMemo } from "react";
const ProductList = memo(function ProductList({ products, onSelect }) {
  const availableProducts = useMemo(() => {
    return products.filter((product) => product.inStock);
  }, [products]);
  const handleSelect = useCallback(
    (productId) => {
      onSelect(productId);
    },
    [onSelect],
  );
  return (
    

{" "}
{availableProducts.map((product) => ( ))}{" "}

);
});

Each hook handles a different part of memoization:

• React.memo: lets React skip rendering ProductList when its props have not changed
• useMemo: caches the filtered products
• useCallback: preserves the function reference between renders

Although these APIs help reduce the amount of work that reaches Fiber, developers still have to decide what to memoize, where to memoize it, and keep dependency arrays up to date.

The React Compiler was introduced to reduce this manual work by adding another layer of optimization. Instead of waiting until runtime to identify unnecessary work, the compiler analyzes components and Hooks during the build process and automatically inserts memoization where it is safe to do so.

This means we can rewrite the same component without the manual memoization hooks:

function ProductList({ products, onSelect }) {
  const availableProducts = products.filter((product) => product.inStock);
  function handleSelect(productId) {
    onSelect(productId);
  }
  return (
    

{" "}
{availableProducts.map((product) => ( ))}{" "}

);
}

During the build process, the compiler analyzes how values depend on props, state, and other values in the component. It can then generate cache checks that reuse availableProducts, handleSelect, JSX elements, or child component output as long as their relevant inputs remain unchanged.

This does not mean the compiler stores the final DOM or bypasses reconciliation. The compiled component still runs within React’s normal rendering system. Fiber still creates and reconciles the work-in-progress tree and decides what should be committed.

Because these two systems serve different purposes, it is easy to mix up their roles. The table below breaks down their key responsibilities and answers common questions about how they work together.

React Fiber vs. React Compiler: Key differences & FAQs

Conclusion

React Fiber transformed React from a rigid tree-traversal tool into an intelligent, schedulable rendering engine. As React continues to evolve through v19 and beyond, Fiber remains the key mechanism powering it all. I hope you enjoyed reading this post.