DEV Community: Anton

React's Component Revolution: How Closures Became the Foundation of Modern UI Components

Anton — Sat, 13 Sep 2025 10:39:38 +0000

Note: In this article I intentionally use the jargon terms "closure" and "variable." The ECMAScript specification doesn’t formally define “closures”—it talks about lexical environments and scope chains—and what we usually call “variables” are technically identifiers bound in environment records. I’m sticking with the jargon here because it’s what the community uses and it makes the discussion more readable.

Every React developer has written hundreds of closures. Many don't realize how central they've become.

When you write:

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

you're not just managing state—you're creating a closure that captures variables from its lexical scope. When React first introduced hooks in late 2018 (and released them in early 2019), it didn’t just give us a new API. It significantly shifted the framework's component architecture from class-based to closure-centric patterns.

The Great Migration: From Classes to Closures

Remember the old days?

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
    this.increment = this.increment.bind(this); // The dreaded bind
  }

  increment() {
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    return <button onClick={this.increment}>{this.state.count}</button>;
  }
}

State lived on component instances. Methods had to be bound. Lifecycle methods were scattered across the class. It was object-oriented, but it was messy.

Then hooks arrived:

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

  const increment = () => setCount(count + 1);

  return <button onClick={increment}>{count}</button>;
}

Cleaner, right? But what's really happening here represents a fundamental shift in how React components work. This isn't just syntactic sugar—it's a completely different approach to component architecture.

What We Mean by "Closure-Based Component Architecture"

To be clear: React's core engine—the reconciler, scheduler, and rendering pipeline—remains largely unchanged. What transformed was how we write and think about components. The closure-based architecture refers specifically to how functional components leverage JavaScript's closure mechanics for state management, effects, and event handling.

React still uses the same virtual DOM diffing, fiber architecture, and scheduling algorithms. Closures have always existed in React — inline event handlers, higher-order components, and render props all used them. But with hooks, closures became the primary mechanism for state, effect, and event management inside components. Component state doesn’t live inside closures. React stores it in its internal fiber structures. Each render just creates a closure that gives you access to the current snapshot of that state.

Welcome to the Closure Factory

Every functional component is essentially a closure factory. When React calls your component function, it creates a closure that captures:

Current state values accessed via useState
Props passed to the component
Context values via useContext
Any variables from outer scopes

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

  // This effect is a closure that captures userId, setUser, and theme
  useEffect(() => {
    fetchUser(userId).then((user) => {
      setUser(user); // Closure captures setUser from outer scope
    });
  }, [userId]);

  // This event handler is also a closure
  const handleEdit = () => {
    editUser(user, theme); // Captures user and theme
  };

  return <div onClick={handleEdit}>{user?.name}</div>;
}

Each render creates fresh closures with new captures. While React's reconciliation engine focuses on virtual DOM diffing and render coordination, it relies heavily on these closures created during each render cycle.

The Beautiful Complexity of Effects

Effects showcase the closure architecture most clearly. Every useEffect creates a closure that captures the component's state at that moment:

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

  useEffect(() => {
    // This closure captures the current value of count
    const timer = setInterval(() => {
      console.log("Current count:", count);
      setCount(count + 1); // Always adds 1 to the captured count value!
    }, 1000);

    // Cleanup is also a closure that captures the specific timer
    return () => clearInterval(timer);
  }, []); // Empty deps = closure never updates

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

This code has a bug—the classic "stale closure" trap, which can also happen with event listeners, async callbacks, or observers that capture old variables. The setInterval callback captures count from when the effect first ran. Even though count changes in React's internal state, the closure still sees the old value because the effect (and its closure) never re-runs.

The fix? Either include count in dependencies (creating new closures) or use an updater function:

useEffect(() => {
  const timer = setInterval(() => {
    setCount((prev) => prev + 1); // No closure dependency on count
  }, 1000);

  return () => clearInterval(timer);
}, []); // Safe with empty deps

The Memory Management Dance

React's closure-heavy architecture creates unique memory challenges. When components unmount, proper cleanup is essential to prevent leaks. Closures don’t block garbage collection on their own — they’re collected like any object — unless something else still holds a reference to them. Problems arise when external systems (timers, subscriptions, event listeners) keep pointing at closures from old renders.

function DataSubscription({ userId }) {
  const [data, setData] = useState(null);

  useEffect(() => {
    const subscription = api.subscribe(userId, (newData) => {
      setData(newData); // Closure references setData for this render
    });

    // Cleanup removes the reference from the external system
    return () => subscription.unsubscribe();
  }, [userId]);
}

Without the cleanup:

The subscription object keeps a reference to the callback closure.
That closure references setData, tied to this component instance’s fiber.
As long as the subscription lives, the closure (and component) stay in memory, even if the component unmounted.

Cleanup functions break this chain. When React unmounts a component, it calls all effect cleanups, removing external references. Once nothing points at the closure anymore, the garbage collector can reclaim it.

Why this matters

Most memory leaks in React apps don’t come from React itself—they come from effects that forget to clean up. Leaks might not be obvious in small components, but at scale (think live dashboards, chat apps, or data-heavy UIs) they add up, slowing the browser and draining memory. Knowing that closures live on as long as anything references them makes it clear why cleanup functions are non-negotiable.

Memoization: Optimizing the Closure Assembly Line

React's memoization hooks (useMemo, useCallback, React.memo) are all about managing closure lifecycles efficiently:

function ExpensiveComponent({ items, onSelect }) {
  const [filter, setFilter] = useState("");

  // Without memoization: new closure every render
  const filteredItems = items.filter((item) => item.name.includes(filter));

  // With memoization: closure reused until dependencies change
  const filteredItems = useMemo(
    () => items.filter((item) => item.name.includes(filter)),
    [items, filter]
  );

  // Prevent child re-renders by memoizing event handler closure
  const handleSelect = useCallback(
    (id) => {
      onSelect(id);
    },
    [onSelect]
  );

  return <ItemList items={filteredItems} onSelect={handleSelect} />;
}

Memoization is React's way of saying: "Don't create new closures unless you have to." In production, memoized values persist until dependencies change. In development and Strict Mode, React may intentionally call your component twice and recreate memoized values to help detect unintended side effects.

The Ripple Effect

React's closure-based approach influenced the entire frontend landscape. Vue 3 introduced the Composition API, which mirrors React's hook patterns. Svelte 5 added "runes" that work similarly to React hooks.

The pattern spread beyond JavaScript. Swift's SwiftUI framework shows clear React influences in its declarative syntax and state management patterns. Kotlin's Compose for multiplatform development mirrors React's declarative approach with @Composable functions that behave like functional components.

The New Mental Model for Components

Understanding React's closure-based component architecture changes how you think about building UI:

Components aren't objects—they're closure factories
Component state is accessed through closures—but stored in React's internal fiber structures
Re-renders create new closures—with fresh captures of current state
Component performance—is about managing closure lifecycle efficiently

Once you see React through the closure lens, everything clicks. Dependency arrays make sense. Stale closure bugs become predictable. Memoization strategies become obvious.

React didn't just introduce hooks—it demonstrated that closures could be a powerful foundation for component architecture. Every functional component leverages JavaScript's closure behavior while React's core engine continues to handle reconciliation, scheduling, and rendering.

The next time you write useState, remember: you're not just managing state. You're participating in an elegant closure-based architecture that changed how we build user interfaces.

What closure patterns have you discovered in your React code? Have you fallen into the stale closure trap? Share your experiences in the comments.

I love finite-state machines:)

Anton — Sun, 11 May 2025 10:44:11 +0000

Hi, my name is Anton. I'm a software developer specializing in cross-platform mobile development, currently working at a fintech company where I help build a neo-banking application.

There's often debate about design patterns—do we really need them, or are they just outdated theory with little practical value in modern software development? I strongly disagree with the idea that patterns are unnecessary. In my view, having a solid foundation in theoretical concepts is extremely valuable. It's like recursion: you might not need it every day, but when you encounter a problem that is recursive in nature—like traversing a file system—you simply can't solve it effectively any other way. The same applies to design patterns. Some processes naturally fit certain patterns, and recognizing them allows you to solve problems in a well-known, structured way. Otherwise, you risk reinventing the wheel—often with a much, much less effective result.

Recently, I was assigned an interesting task at work that proves my point, and I think it's worth sharing.

In my daily work, I'm always looking for patterns that can help implement features more cleanly and maintainably. Since I mostly work on the client side, which is inherently stateful, one of my favorite patterns is the finite-state machine. Even if you know nothing about state machines, you're probably using them unconsciously in your code. The reason is that state machines are incredibly common in our daily lives - they appear in everything from traffic lights and vending machines to smartphone apps and ATMs. Any system that moves through specific states in response to certain inputs or events is essentially a state machine. We interact with them constantly, often without realizing it. But if you use them unconsciously, they usually end up as a messy combination of boolean flags and if statements. It's hard to add new states, and each additional state makes the abstraction worse and worse. It's much better if you can recognize the pattern and organize it properly.

That's exactly the situation we had. My team and I are pretty obsessed with code quality. During a regular upgrade of our dependencies (a routine process in any React Native app), we decided to migrate to the latest version of React Navigation, and as part of that process, refactor some connected features. While investigating what to improve, the identity verification process caught our attention. Like in any banking app, a crucial part of ours is verifying customer identity and documents during onboarding. This is a fairly complex process, involving many steps, and in our app, it was spread across nine screens. And the original implementation, to be honest, was far from ideal. It seemed like previously nobody had tried to see the whole picture. Each screen was treated as a separate entity, and as a result, the logic for each step was spread throughout the functional component body—often 50 to 150 lines of business logic per screen, right in the render method. The communication between screens was also poor. All data was passed through route params, which is fine for primitive values but becomes unwieldy for complex objects used across multiple screens.

Before: Passing Everything Through Navigation Params

// SomeDocumentScreen.tsx
export const SomeDocumentScreen = ({ route }) => {
  const { navigate } = useNavigation();

  // Complex business logic directly in component
  // Passing all params through, for the next screens
  const handleNextStep = (path) => {
    const { firstStepData } = route.params;

    if (firstStepData) {
      navigate("SecondStepScreen", {
        ...route.params,
        type: "typeB",
        firstStepData: { ...firstStepData, path }
      });
    }
  };

  const handleRetry = (error) => {
    const { type, firstStepData } = route.params;
    const retryInfo = determineRetryPath(error);

    navigate("RetryStepScreen", {
      ...route.params,
      failed: retryInfo.failed,
      maxAllowedRetries: 0
    });
  };

  return (
    // Components UI...
  );
};

Some screens didn't need more than half of the params, but were forced to accept them because the next screen needed them, which is a direct violation of the interface segregation principle. It became almost impossible to track which screen actually needed which params. We could have continued treating it as nine separate screens, maybe refactored here and there, or moved some data from params to a state manager. That would have been a slight improvement, but still not what I wanted.

Instead, I decided to take a step back and look at the whole process from a wider perspective. I immediately noticed that it was really a single, complex process with nine clear steps—each of which could be represented as a separate state with the clear transitions between them. I was excited, this was a perfect case for the finite-state machine pattern!

I started planning how to improve this feature, but the complexity made it hard to see the full picture. To help myself, I decided to visualize the process first. I spent about two days preparing a flowchart of the entire process, and only after that did I start working on the implementation.

The Refactoring: Step by Step

I started by creating the structure of the state machine, declaring all the steps, and preparing an object to connect each state to its corresponding screen.

// ProcessSteps.ts
export const processSteps = {
  FIRST_STEP: "FirstStep",
  SECOND_STEP: "SecondStep",
  // Additional steps...
  RETRY_STEP: "RetryStep",
} as const;

export type ProcessState = (typeof processSteps)[keyof typeof processSteps];

export const stateToScreen: Record<ProcessState, ScreenNames> = {
  [processSteps.FIRST_STEP]: "FirstStepScreen",
  [processSteps.SECOND_STEP]: "SecondStepScreen",
  // Mapping additional steps to screens...
  [processSteps.RETRY_STEP]: "RetryStepScreen",
};

I also wrote navigation helpers to handle the different navigation actions. Since React Navigation v7 requires the navigation object to come from a hook and only be used inside component bodies, I passed it to the state machine transition functions as a dependency.

// Helper functions to handle different navigation actions
export const navigateToState = (
  state: ProcessState,
  navigate: NavigateFunction,
  params?: Record<string, any>
) => {
  const screenName = stateToScreen[state];
  navigate(screenName, params);
};

export const resetToState = (state: ProcessState, reset: ResetFunction) => {
  const screenName = stateToScreen[state];
  reset({
    index: 0,
    routes: [{ name: screenName }],
  });
};

export const pushToState = (
  state: ProcessState,
  dispatch: DispatchFunction
) => {
  const screenName = stateToScreen[state];
  dispatch(StackActions.push(screenName));
};

Once this preparation was done, I began gradually moving the business logic from each screen into the respective state in my state machine, step by step. This process took at least two weeks, including testing each step to make sure nothing broke. I also made a point not to change the logic itself, since it was already working well—there was no need to make the task even more complicated. I focused solely on changing the structure, making the transition as safe and minimal as possible.

To manage the state of our finite-state machine and house its transition logic, I leveraged our existing client-state management solution, Zustand. The createProcessStore function, shown below, defines this logic. It's worth noting that the FSM pattern itself is flexible; you could implement it with vanilla React hooks, Context API, or other state management libraries. For applications with numerous or highly complex state machines, dedicated libraries like XState are also excellent choices, offering powerful features such as formal definitions, visualizers, and actor model capabilities.

The Result

I was very satisfied with the result. Now, the business logic is encapsulated in one place, and it's easy to understand the whole flow just by looking at the code for each step. In fact, it's so clear and self-documenting that you barely need the flowchart anymore.

// ProcessStore.ts
export const createProcessStore: StateCreator<ProcessStore> = (set, get) => ({
  // Initial state
  currentState: undefined,
  type: undefined,
  firstStepData: { path: undefined, success: false, id: undefined },
  secondStepData: { path: undefined, success: false, id: undefined },

  // Utility methods
  clear: () => set(() => initialState),

  // State transitions
  // Business logic that previously lived in the components body
  navigateToFirstStep: (navigate) => {
    // Logic to transition to the first step
    set((state) => ({
      ...state,
      currentState: processSteps.FIRST_STEP,
      type: "typeA",
      // Update state related to the transition
    }));

    navigateToState(processSteps.FIRST_STEP, navigate);
  },

  navigateToSecondStep: (dispatch, path) => {
    // Logic to transition to second step state
    set((state) => {
      const dataKey = getDataKey(state.type);
      return {
        ...state,
        currentState: processSteps.SECOND_STEP,
        [dataKey]: { ...state[dataKey], path },
      };
    });

    pushToState(processSteps.SECOND_STEP, dispatch);
  },

  // Additional state transitions for each step in the process
  // ...

  // Error handling state transitions
  handleRetry: (navigate, failed) => {
    // Logic to handle retry logic
    set((state) => ({
      ...state,
      currentState: processSteps.RETRY_STEP,
      tasksInProgress: { completed: [], remaining: failed },
      maxAllowedRetries: 0,
    }));

    navigateToState(processSteps.RETRY_STEP, navigate, {
      // Params to pass ...
    });
  },
});

The screens themselves became much more "dumb"—they no longer handle any business logic, but simply use the functions provided by the state machine.

// SomeDocumentScreen.tsx
export const SomeDocumentScreen = () => {
  const { navigate, dispatch } = useNavigation();

  const { navigateToSecondStep, handleRetry } = useProcessStore();

  const handleNextStep = (path: string) => {
    navigateToSecondStep(dispatch, path);
  };

  const handleError = (error: Error) => {
    const retryInfo = determineRetryPath(error);
    handleRetry(navigate, retryInfo.failed);
  };

  return (
      // Components UI...
  );
};

While some FSMs use a generic transition function, like proceedToStep(targetState, ...params), I chose specific methods for each state transition (e.g., navigateToSecondStep). This was my conscious decision to maintain clarity ,type safety and simplicity, as each transition in our process had distinct parameter requirements, making a single generic dispatcher less practical for this use case.

As a pleasant side effect, I was able to delete many lines of redundant code that were, in fact, not in use—but it wasn't obvious before, and everyone was afraid to remove it for fear of breaking something. I shudder to think what it would have been like if we had needed to add new features or extend this code in its previous form—it would have been a nightmare. Now, the code is much better structured, clearer, far more maintainable, and easy to extend with new features in the future.

Key Takeaways

Recognize the Pattern: Taking a step back to see the bigger picture revealed that our nine separate screens were actually a single process with distinct states - a perfect match for the finite-state machine pattern.
Centralized Logic: Moving business logic from individual components into a dedicated state machine significantly improved code organization and maintainability.
Cleaner Components: UI components became simpler "dumb" presentational components, focused solely on rendering and user interaction rather than complex business logic.
Self-Documenting Code: The state machine structure made the flow so clear that it serves as documentation - you can understand the entire process just by reviewing the state transitions.
Easier Debugging: Finding and fixing bugs became much simpler with a centralized, structured approach to state management.
Reduced Code: As a bonus, we were able to safely remove redundant code that was previously difficult to identify as unused.
Future-Proofing: Adding new features or states to the process is now straightforward since the pattern scales well with additional complexity.
Theoretical Knowledge Has Practical Value: This real-world example demonstrates why understanding design patterns like finite-state machines remains valuable in modern software development.

The time investment in refactoring (approximately two weeks) has already paid dividends in terms of code quality and maintenance efficiency. What initially seemed like a daunting task - refactoring nine complex screens - became manageable by applying the right pattern to the problem.

Thank you for your attention and happy hacking!