How useState works under the hood

By Sachintha Gunaratne 14 min read
React JavaScript

How React tracks state under the hood, from Fiber nodes and update queues to Object.is comparisons and automatic batching.

useState looks simple. Call const [count, setCount] = useState(0) and React tracks the value for you. Behind that one line sits a system of memory management, update queues, and reconciliation logic that decides how and when your component re-renders. It shares the same foundation as useEffect.

Most of us treat useState as a black box. It works, until an app grows and a re-render happens for no obvious reason, or performance turns critical. That's when knowing what's underneath actually saves debugging time.

React's Fiber architecture

Fiber nodes

React's internal architecture is built around a data structure called Fiber. Each component you write becomes a fiber node, and together they form a tree that mirrors your component tree.

Every fiber node carries what React needs to know about that component:

  • stateNode: the actual component instance or DOM node
  • child: the first child fiber
  • sibling: the next fiber at the same level
  • return: the parent fiber
  • memoizedState: where your hooks live
  • alternate: the fiber's other version, used during updates

When you call useState, React doesn't drop your state into an arbitrary memory slot. It builds a linked list attached to the component's fiber node, and each useState call becomes one link in that list, stored in memoizedState.

The work-in-progress tree

React uses double buffering. Rather than editing your component tree directly, it builds a separate "work-in-progress" tree and applies every update there first.

That separation gives React a few guarantees:

  • React finishes all updates before anything renders on screen
  • Updates can pause and resume without exposing a half-finished state
  • Comparing the work-in-progress tree against the current one shows exactly what changed
  • If something goes wrong mid-update, the current tree stays untouched

Only after the work-in-progress tree is fully ready does React commit it, swapping it in as the new current tree. That's what keeps you from ever seeing an in-between state.

Hook registration and state association

Mount vs. update

useState behaves differently on a component's first render than on every render after that.

On the first render, the "mount", React calls mountState(), which:

  1. Creates a new hook object with mountWorkInProgressHook()
  2. Stores the initial state in both hook.memoizedState and hook.baseState
  3. Creates an update queue for future state changes
  4. Binds dispatchSetState as the setter function you call, like setCount

The hook object looks like this:

const hook = {
  memoizedState: initialState, // Current state value
  baseState: initialState, // Base state for updates
  baseQueue: null, // Base update queue
  queue: {
    // Update queue configuration
    pending: null,
    lanes: NoLanes,
    dispatch: null,
    lastRenderedReducer: basicStateReducer,
    lastRenderedState: initialState,
  },
  next: null, // Reference to next hook
};

On every render after the mount, React calls updateState() instead. It walks to the existing hook in the linked list and processes whatever updates are pending, rather than creating anything new.

Hook call order matters

React matches hooks to their stored data by position, not by name. As it processes your component function, it walks a pointer through the hook linked list, one step per hook call. That's why the Rules of Hooks exist:

  • No hooks inside conditions, loops, or nested functions
  • Call hooks in the same order every render
  • Only call hooks from React function components or custom hooks

Break these rules and React can't line up your hook calls with their stored values. The result is state corruption and behavior that doesn't map to anything in your code.

Update queues and memory

The circular linked list

When you call a setter like setCount(5), React doesn't update state immediately. It creates an update object and adds it to a circular linked list, queuing the change instead of applying it right away.

This queue is what lets React batch multiple updates and handle different priority levels. Each update object carries what React needs to process it later:

const update = {
  lane: updateLane, // How urgent is this update?
  action: newValue, // What's the new value or function to run?
  hasEagerState: false, // Did we already figure out the result?
  eagerState: null, // The eagerly computed result (if any)
  next: null, // Who's next in line?
};

Updates start in a global concurrentQueues array and move to the fiber's hook queue once rendering begins. That two-stage handoff lets React accept updates that happen during rendering without corrupting the render already in progress.

Priority-based updates

React's concurrent features assign each update a priority through "lanes":

  • User input, like a click, gets SyncLane and runs first
  • Data fetching updates run at a more relaxed pace
  • Background updates run last

If a high-priority update arrives while React is working through something lower priority, it pauses the lower-priority work and handles the urgent update first. The paused work isn't lost, it sits in baseQueue until a future render picks it back up.

This priority system is what makes time-slicing possible. Instead of processing everything in one block, which would freeze the UI, React breaks the work into pieces it can interrupt when something more urgent comes in.

State comparison and bailout

The Object.is comparison

React compares state values with Object.is() instead of ===. Object.is() handles NaN correctly and distinguishes +0 from -0, edge cases === gets wrong.

If the new state is identical to the current state by that comparison, React can skip re-rendering the component and its children entirely, a real performance win when nothing actually changed.

React has two kinds of bailout, and they happen at different points ("early" and "regular" are just descriptive names for this post, not terms you'll find in React's own source):

  • Early bailout, before React even schedules a re-render. The cheapest option.
  • Regular bailout, during the render phase itself. Still useful, just later.

Why you sometimes get two renders

One of React's more confusing behaviors: setting state to the value it already has can still trigger a render.

This comes from how conservative the early bailout check is. It requires both the current fiber and its alternate to have no pending work at all (NoLanes). When an update gets enqueued, both fibers get marked dirty, and the alternate fiber's lanes only clear during the actual render. That means the early bailout check can fail on the very next identical update, even though nothing will end up changing.

So the component can render twice before React confirms nothing changed. That's not a bug, it's React trading an occasional extra render for correctness.

Automatic batching in React 18

From manual to automatic batching

Before React 18, batching only happened inside React event handlers like onClick or onChange. Updates inside promises, timeouts, or native event handlers each triggered their own render.

React 18 batches updates automatically, regardless of where they come from:

// Before React 18: 3 separate renders
setTimeout(() => {
  setCount((c) => c + 1); // Render 1
  setName("John"); // Render 2
  setEmail("john@example.com"); // Render 3
}, 1000);

// React 18: 1 batched render
setTimeout(() => {
  setCount((c) => c + 1); // Queued
  setName("John"); // Queued
  setEmail("john@example.com"); // All batched into one render
}, 1000);

For apps that update state frequently, this cuts out renders that were never doing useful work.

Batching and concurrent features

Automatic batching works alongside React's concurrent features, like time-slicing and Suspense. Updates from user events, network responses, and timers all get batched and processed at the right priority.

High-priority updates, a click for instance, still run immediately. Lower-priority updates, like background data loading, batch efficiently without blocking anything urgent.

Debugging useState with React DevTools

useDebugValue for custom hooks

useDebugValue labels a custom hook's state so it's readable in React DevTools instead of showing a raw internal value.

function useCounter(initialValue) {
  const [count, setCount] = useState(initialValue);

  // Labels the state for DevTools instead of showing a raw value
  useDebugValue(`Counter: ${count}`);

  return [count, setCount];
}

Inspecting this component in DevTools shows "Counter: 5" instead of an opaque internal value.

Hook order violations

The "React has detected a change in the order of Hooks" error shows up when hooks get called conditionally or in a different order between renders. DevTools points to exactly which hooks moved.

Common causes:

  • Early returns before every hook has run
  • Conditional hook calls based on props or state
  • Dynamic imports that change hook execution order

The fix is always the same: call hooks in the same order on every render. Usually that means moving conditional logic inside the hook body instead of wrapping the hook call itself.

Memory management and cleanup

Preventing memory leaks

useState itself rarely leaks memory, but the values it holds can. Large objects in state need explicit cleanup when a component unmounts.

function DataComponent() {
  const [largeDataSet, setLargeDataSet] = useState([]);

  useEffect(() => {
    fetchLargeData().then(setLargeDataSet);

    // Clean up when component unmounts
    return () => {
      setLargeDataSet([]); // Release that memory
    };
  }, []);

  return <div>{largeDataSet.length} items loaded</div>;
}

React doesn't garbage-collect state values on unmount by itself. A large dataset sitting in state stays in memory until something clears it.

Handling async operations

Memory leaks are common when an async operation resolves after its component has already unmounted. The work still runs, but there's nothing left to receive the result.

function AsyncDataComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    let isMounted = true; // Our safety flag

    fetchData().then((result) => {
      if (isMounted) {
        setData(result); // Only update if we're still around
      }
    });

    return () => {
      isMounted = false; // Flip the switch when we're done
    };
  }, []);

  return <div>{data ? "Data loaded" : "Loading..."}</div>;
}

This pattern uses useEffect's cleanup mechanism to prevent state updates on an unmounted component, avoiding the "Can't perform React state update on unmounted component" warning.

Performance optimization

Re-render triggers

React triggers a re-render when its Object.is() check finds a state change. Knowing when and why that happens matters most alongside useEffect's dependency arrays, since state changes there can cascade into side effects.

A few rules keep re-renders under control:

  • Create new objects or arrays instead of mutating existing ones. React relies on reference changes to detect updates.
  • Update only the specific state that changed, not the whole shape.
  • Shape your state to minimize what has to re-render when one thing changes.
  • Use React.memo, useMemo, and useCallback where they earn their cost, not everywhere.

Normalizing state

Normalizing state structure helps once state gets complex enough that updating one item shouldn't re-render a whole list.

// Less efficient: updating one user causes the entire list to re-render
const [users, setUsers] = useState([
  { id: 1, name: 'John', posts: [...] },
  { id: 2, name: 'Jane', posts: [...] }
]);

// More efficient: normalized structure (like having separate drawers)
const [users, setUsers] = useState({ 1: { id: 1, name: 'John' }, 2: { id: 2, name: 'Jane' } });
const [posts, setPosts] = useState({ 1: [...], 2: [...] });
const [userIds, setUserIds] = useState([1, 2]);

With state normalized this way, updating one user's name only re-renders the components that actually read that user, not the whole list.

Reach for this once profiling actually shows the flat structure causing re-renders that matter, not before. Normalizing state you didn't need normalized just trades one problem for another. Instead of extra re-renders, you've got three pieces of state that can drift out of sync. Most component-local state never grows large enough for that trade to pay off.

Concurrent mode integration

Time-slicing and useState

React's concurrent mode breaks rendering work into small chunks, "time slices", so the browser can handle other work between them instead of blocking on one long render, the same single-thread bottleneck the event loop manages for everything else running in the browser.

During time-slicing, a useState update can get interrupted and resumed. React might start processing an update, pause for urgent input like a click or scroll, resume where it left off, then complete the render once it's safe.

This keeps the app responsive even while React works through large state updates or deep component trees.

Suspense integration

useState works well with Suspense boundaries for data fetching. When a component suspends while loading data, its useState values stay intact until the async operation finishes, no resets, no surprises, as long as the component's fiber stays around, hidden behind the fallback, instead of being torn down. If the subtree actually unmounts, state resets like it would for any other unmount. This lines up with useEffect's asynchronous execution model, where effects run after the commit phase.

That means the UI can stay interactive while data loads in the background, instead of falling back to a loading spinner.

Common pitfalls

Stale closures

A closure that captures old state and never sees the updated value is one of the most common gotchas in React.

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

  useEffect(() => {
    const timer = setInterval(() => {
      setCount(count + 1); // ❌ Stale closure - always adds 1 to initial value
    }, 1000);

    return () => clearInterval(timer);
  }, []); // Empty dependency array causes stale closure

  return <div>{count}</div>;
}

The fix is a functional update, or including the right dependencies:

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

  useEffect(() => {
    const timer = setInterval(() => {
      setCount((prevCount) => prevCount + 1); // ✅ Always uses current value
    }, 1000);

    return () => clearInterval(timer);
  }, []); // Now safe with functional update

  return <div>{count}</div>;
}

useEffect's dependency tracking makes sure the effect only re-runs when it needs to, while the functional update avoids reading a stale value.

Unnecessary re-renders from object references

Creating a new object or array inline during render causes unnecessary re-renders. React sees a new reference and assumes something changed, even when the underlying data is identical.

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  // ❌ Creates new array every render (even if user.skills didn't change)
  const skills = user?.skills || [];

  return <SkillsList skills={skills} />;
}

useMemo keeps the reference stable across renders where the input hasn't changed:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  // ✅ Stable reference when user.skills doesn't change
  const skills = useMemo(() => user?.skills || [], [user?.skills]);

  return <SkillsList skills={skills} />;
}

FAQ

How does useState maintain state between renders?

useState stores values in fiber nodes, inside a linked list held on the fiber's memoizedState property. On re-render, React doesn't recreate that state, it reads it back from the fiber.

Why do hook calls need to be in the same order every time?

React matches hook calls to their stored data by position, not by name. A different call order means React can't line up the right call with the right data, which produces state corruption. That's why conditional hook calls aren't allowed.

What happens when I set state to the same value?

React runs an Object.is() check against the current state. If they match, React tries to bail out of re-rendering. Because of how the bailout condition is structured, you can still see one or two renders before React confirms nothing changed. That's an intentional trade-off, not a bug.

How does automatic batching work in React 18?

React 18 groups multiple state updates into a single render regardless of where they originate, promises, timeouts, and event handlers included. Earlier versions only batched updates inside React event handlers, so each of those other cases got its own render.

Can useState cause memory leaks?

useState itself is safe. The values it holds aren't always. Large objects in state need cleanup on unmount, and async operations that resolve after unmount can keep references alive longer than they should.

How do I debug complex useState behavior?

Start with React DevTools for inspecting state values. Add useDebugValue to custom hooks for better visibility, and log state changes directly when needed. Most of this comes down to understanding the component's lifecycle and what triggers each re-render.

What's the difference between setState in class components and useState?

Class setState merges the object you pass into existing state automatically. useState replaces the value outright, so you spread the old state yourself if you want to merge. useState also supports functional updates, and each call manages one independent piece of state rather than one shared object.

How does useState work with concurrent features?

It integrates directly with time-slicing and Suspense. Updates can be interrupted, resumed, prioritized, and batched automatically without any extra code from you.

Wrapping up

Understanding useState's internals changes how you read a bug report. Fiber architecture, update queues, memory management, and concurrent features aren't separate trivia, they're the reasons your component re-renders when it does.

That understanding pays off in specific ways: you can tell why a re-render happened instead of guessing, spot hook order violations and stale closures on sight, and design state that works with React's optimizations instead of against them.

useState looks simple on the surface. The mechanics underneath, fiber nodes, lanes, bailouts, batching, are what make it fast at scale. None of this is academic. It's the same foundation useEffect is built on, so the next time a side effect fires at the wrong moment, this is where to start looking.

None of this makes re-rendering components the only way to model UI state. Frameworks built around signals track dependencies at the value level instead, updating just the DOM node that reads a value rather than re-running a whole component. That's a real trade-off in framework design, not a settled question, but it's a useful reminder that fiber and reconciliation are React's answer, not the only one.