DEV Community: Mashuk Tamim

Mastering React's useState: A Deep Dive into Stale Closures, Batching, and Functional Updates

Mashuk Tamim — Wed, 02 Jul 2025 18:12:31 +0000

Have you ever found your React state updates behaving in unexpected ways? Perhaps a simple counter increments by one instead of two, or a console.log stubbornly displays an outdated value, leaving you puzzled.

These common frustrations often stem from a fundamental misunderstanding of how React's useState hook processes updates. This post aims to provide a comprehensive understanding, delving into the nuances of state updates, the critical role of "stale closures," React's "batching" mechanism, and the definitive solution: "functional updates."

The Two Approaches to useState Updates

Let's begin by examining the two primary ways developers interact with the setCount function returned by useState. We'll use a simple counter component for illustration.

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  // Version 1: The "Direct Update" approach
  const directUpdate = () => {
    setCount(count + 1);
    setCount(count + 1);
    console.log("Direct Update - Logged count:", count);
  };

  // Version 2: The "Functional Update" approach
  const functionalUpdate = () => {
    setCount(prev => prev + 1);
    setCount(prev => prev + 1);
    console.log("Functional Update - Logged count:", count);
  };

  return (
    <div>
      <h2>Count: {count}</h2>
      <button onClick={directUpdate}>Direct Update (+2 Expected)</button>
      <button onClick={functionalUpdate}>Functional Update (+2 Expected)</button>
    </div>
  );
}

Upon running this code, a key observation emerges:

Clicking "Direct Update (+2 Expected)" results in the count incrementing by only 1.
Clicking "Functional Update (+2 Expected)" correctly increments the count by 2.
In both cases, the console.log statement within the respective event handlers outputs 0 (the initial state), not the expected updated value.

This behavior highlights crucial aspects of React's state management.

Understanding the "Direct Update" Approach (setCount(count + 1))

When you use setCount(count + 1), you are instructing React to set the new state value based on the count variable available in the current execution scope. The fundamental issue here lies with "stale closures."

The count variable accessed within the directUpdate function is "closed over" from the specific render cycle in which that Counter component instance was created. This means it holds the value of count at the time that particular directUpdate function was defined, not necessarily the most current or pending state.

Let's trace directUpdate assuming count is initially 0:

A user clicks "Direct Update".
The directUpdate function is invoked. Within this specific function's scope, the count variable holds the value 0 (from the last completed render).
setCount(count + 1) is called, which resolves to setCount(0 + 1), effectively setCount(1). React schedules this update.
Immediately after, setCount(count + 1) is called again. Crucially, the count variable within this same function execution context is still 0. So, this resolves to setCount(0 + 1), resulting in another setCount(1). React schedules this second update.
React now has two pending updates, both requesting to set count to 1. Due to its batching mechanism (discussed below), these updates are processed efficiently, and the final state becomes 1.

The console.log(count) also outputs 0. This is because the count variable within the directUpdate function's closure reflects the state before React has processed the updates and re-rendered the component. State updates are asynchronous from the perspective of the immediate JavaScript execution.

Unpacking the "Functional Update" Approach (setCount(prev => prev + 1))

The functional update approach offers a robust solution to the challenges posed by stale closures. By passing a function (e.g., prev => prev + 1) to setCount, you provide React with a callback. React then executes this callback, providing the most recent previous state as the prev argument, ensuring the calculation is always based on the freshest possible data.

Let's trace functionalUpdate assuming count is initially 0:

A user clicks "Functional Update".
The functionalUpdate function is invoked.
setCount(prev => prev + 1): React receives this function. When it's ready to process the update, it internally takes the current state (0), invokes the provided function (0 + 1), and internally queues the state to become 1.
setCount(prev => prev + 1): React receives this second function. Critically, when it comes to process this update, it uses the pending state from the previous update (which is now 1). It then invokes the function (1 + 1), and internally queues the state to become 2.
Through its batching mechanism, React efficiently calculates the final state as 2 from these chained updates and performs a single re-render.

Similar to the direct update, console.log(count) within functionalUpdate will still output 0. This reaffirms that the count variable in the component's closure reflects the state before React's asynchronous update and re-render cycle completes.

Key Concepts: Batching, Asynchronicity, and the JavaScript Event Loop

A thorough understanding of these concepts is crucial for mastering useState:

1. React's Batching Mechanism

Purpose: React groups multiple state updates that occur within the same event loop cycle (e.g., within a single event handler execution) into a single re-render. This optimizes performance by preventing unnecessary multiple renders.
Behavior with Direct Updates: In our directUpdate example, both setCount(1) calls are batched. React effectively receives two independent instructions to set the state to 1. The second instruction doesn't "know" about the first pending instruction's effect on the state calculation, leading to 1 as the final result.
Behavior with Functional Updates: With functional updates, batching works seamlessly because React processes the update functions sequentially. Each subsequent functional update receives the result of the previous update as its prev argument, ensuring the updates are correctly chained to arrive at the desired final state.
Automatic Batching (React 18+): A significant enhancement in React 18 is automatic batching for all state updates, regardless of their origin (event handlers, promises, setTimeout, etc.), as long as they occur within the same "event loop tick." This greatly simplifies state management predictability.

2. Asynchronous Nature of useState Updates

From the perspective of your component's immediate JavaScript execution, useState updates are asynchronous. When you call setCount, the state doesn't instantly change in the very next line of your code. Instead, React schedules the update. The actual state change and subsequent re-render happen later, after your current function finishes executing and React processes its internal update queue.
This asynchronous behavior is why console.log(count) always displays the old value within the event handler function. The count variable in that specific closure reflects the state before React has committed the new state and re-rendered the component.

3. The JavaScript Event Loop

The JavaScript Event Loop is fundamental to how asynchronous operations are managed in a single-threaded environment.
When a user clicks a button, a "click" event is placed into the Event Queue.
Once the Call Stack (where synchronous JavaScript code executes) is empty, the Event Loop pushes the event handler (directUpdate or functionalUpdate) from the Event Queue onto the Call Stack for execution.
During the execution of your event handler, setCount calls are encountered. These calls do not block the Call Stack; they simply schedule updates with React. The console.log statement executes synchronously at its position within the function.
After your event handler completes and the Call Stack is empty, React can then process its batched, scheduled updates, calculate the new state, and finally trigger a re-render of your component with the updated state.

The Definitive Choice: Functional Updates

When the new state depends on the previous state, the functional update form (setCount(prev => prev + 1)) is the superior and recommended approach.

Why it's essential for mastery:

Guaranteed Correctness: It eliminates the risk of "stale closures," ensuring your state calculations always operate on the most accurate and up-to-date state value.
Predictable Chaining: For scenarios involving multiple state updates within a single operation, functional updates correctly chain these operations, leading to the precise final state you intend.
Robustness with Concurrent React: It seamlessly integrates with React's advanced concurrent rendering capabilities, providing a more resilient and predictable state management pattern, especially as React evolves.

While direct updates (setCount(newValue)) can be acceptable when the new state is entirely independent of the previous state (e.g., setLoading(true)), adopting the functional update pattern whenever there's a dependency on the previous state is a hallmark of robust and idiomatic React development.

By deeply understanding these underlying mechanisms, you move beyond mere syntax and gain true mastery over React's useState hook, empowering you to build more reliable and performant applications.

Is Your Shadcn UI Project at Risk? A Deep Dive into Radix’s Future

Mashuk Tamim — Mon, 30 Jun 2025 06:54:09 +0000

A recent "hot take" from Chris, a trusted contributor to the Create T3 App, sparked a significant discussion in the web development community: is using Shadcn UI, and by extension Radix, a liability? This question has ignited a debate about the maintenance of these popular UI component libraries and the future of UI development.

Understanding the Players: Shadcn UI and Radix

To understand the core of the issue, it’s crucial to differentiate between Shadcn UI and Radix:

Shadcn UI: This isn’t a traditional component library but rather an “idea” — an open abstraction with great defaults and a distribution system. It combines Tailwind for styling, Radix for behaviors, and its own custom styles for appearance. A key differentiator is that when you use Shadcn UI, you get the source code directly in your codebase, allowing for greater ownership and customization.
Radix Primitives: Radix is primarily known for its “headless behaviors” or “primitives.” These are the underlying functionalities for components like dropdowns, dialogues, and popovers, handling aspects like focus management and keyboard navigation. Radix provides the behavior, but you bring your own styles.

The Concerns Around Radix’s Maintenance

The core of Chris’s “hot take” stems from concerns about Radix’s maintenance. Radix was initially built by the startup Modulz, which later became defunct. The Radix team was then acquired by WorkOS, a company that needed better component libraries for integrating authentication into React applications.

While WorkOS initially aimed to continue maintaining Radix, many of the original maintainers have since left to pursue other ventures. This has led to a significant slowdown in contributions to the Radix open-source project, with a concerning number of open issues and pull requests. The original co-creator of Radix, Colem, even stated that Radix is a “liability” and the “last option” he’d consider for a serious project.

A significant example of these maintenance issues is a bug where the Radix library aggressively calls setState internally, leading to "update depth being exceeded" errors, especially in applications with many components. This particular issue was closed without being fixed for a long time and was caused by useEffect hooks lacking dependency arrays, leading to constant re-renders.

The Impact on Shadcn UI Users

Given that Shadcn UI heavily relies on Radix for its component behaviors, the maintenance concerns directly impact Shadcn UI users. Companies like Axiom, which handles massive amounts of data and requires highly performant UIs, have encountered these Radix-related performance issues.

However, Shadcn UI’s unique architecture offers a potential solution. Since Shadcn UI components provide the source code directly to your codebase, users have the flexibility to modify or even replace the underlying Radix implementation if any issues arise.

The Path Forward: Alternatives and Shadcn’s Stance

Despite the concerns, the creator of Shadcn UI acknowledges the situation and offers guidance:

Stick with Radix for existing projects: If you’re already using Radix in production, switching component libraries is likely to introduce more bugs and consume valuable resources. Radix is still a mature and battle-tested library, and its code doesn’t simply stop working because maintainers move on.
Consider alternatives for new projects: For new projects, options like Radix, React Aria, or Aria Kit are recommended.
Keep an eye on Base UI: Base UI, built by the same team that created Radix, is emerging as a promising alternative with a similar API, making migration from Radix relatively easy. While currently in beta, it’s actively maintained.
Leverage Shadcn UI’s modularity: Shadcn UI’s design allows users to own and modify the code. If performance issues arise with Radix, parts of Shadcn UI usage can be moved to use Base UI instead.

Ultimately, the goal is to use a stable and understandable component library that works for your needs. While Radix’s maintenance has been a concern, WorkOS is now investing in its maintenance, with skilled developers like Chance stepping in to address existing issues. The modular nature of Shadcn UI also provides a strong safety net, allowing for flexibility and adaptation as the UI landscape evolves.