State Management Architecture. Part 1. From Traditional Redux to RTK

This article is the first part of a series of publications by a recognised and experienced frontend engineer Anton An about the best frameworks for state-management.

Modern applications often serve vast user bases — as of the third quarter of 2024, Meta’s Family of Apps (Facebook, Instagram, Messenger, WhatsApp, Threads) had approximately 3.29 billion daily active users (DAP), representing a 5% YoY increase compared to Q3 2023 [according to Meta Reports Third Quarter 2024 Results]. This immense scale drives high-velocity development cycles, with high-performing teams deploying changes multiple times per day. Such scale and dynamism create significant challenges in managing application state. – the ever-changing data that dictates what users see and interact with. Ensuring consistency and maintainability under these conditions is paramount. This is where state management architectures become crucial for handling this complexity effectively.

They offer ways to centralize and manage data flow, but the landscape of tools is diverse, each with its own philosophy and trade-offs. How do you determine the best fit for your project? This article dives into three prominent solutions in the React ecosystem – Redux, RTK Query, and Zustand – exploring their core concepts, strengths, weaknesses, and ideal use cases to help you make an informed decision based on your specific challenges.

Introduction

In application development, ‘state’ refers to the data that describes the application at any given point in time. This includes data fetched from servers, user inputs, UI statuses (like whether a modal is open or a button is disabled), and more. In complex applications, like banking platforms or government service portals, managing this state accurately is crucial, as errors can have significant consequences. Ensuring each part of the UI reflects the correct state and updates predictably requires a robust architecture.

“Under the Hood” – if everything is saddled in a modern, micro-frontend architecture – these interactive forms, modals and buttons looks as a lot of components of React or other JavaScript framework on which the project is written. One for each smallest setting that a visitor can set in the user interface. This is the only way for platforms that provide government services or allow you to transfer a million dollars in a single transaction. The cost of error of any highly loaded application will be incredibly high!

A state manager provides a centralized store for the application’s state. Instead of passing data down through many component layers (prop drilling), components can access or update the state directly through the manager’s API (e.g., using hooks or selectors). This centralizes state logic, making application data flow more predictable, easier to debug, and simpler to manage, especially as complexity grows.

React, one of the most popular UI libraries today, launched in 2013. Soon after, libraries like Redux (2015) emerged to tackle complex state management challenges in large React applications. While React’s built-in tools (like Context and useReducer) and other patterns certainly have their place depending on the scale and type of state, dedicated state management libraries gained popularity for providing structure and advanced capabilities for complex scenarios. Today, the ecosystem offers evolved and diverse options like Redux Toolkit (an evolution of Redux), Zustand (a minimalist alternative), and specialized tools like RTK Query for server state, which we will compare in this article.

The Evolution of State Management

The “oldest” way to manage state in a React or Vue.js application was to pass data down through component trees via props, often through components that didn’t need the data themselves. In the React community, this is known as ‘prop drilling’. The problem was that as soon as a project became larger than several components, any changes affected the connected properties and required changes not in one component, but in all those components that depended on the edited part of the project through one or another property.

What was a problem in more or less complex code turned into a disaster in a large, highly loaded project. Controllability of states was completely lost. It was difficult for developers to figure out what they had and where. Maintaining such code was incredibly difficult, and it created a serious technical debt.

Things started to change for the better with the introduction of the React Context API. This built-in library made data available in multiple components. Something like a “superglobal variable”.

// Create a Context for the mission data
const MissionContext = createContext();

// Mission Provider component to wrap the app and provide mission data
function MissionProvider({ children }) {
  const [missionData, setMissionData] = useState({
    astronauts: [
      { id: 1, name: 'Alex Carter', role: 'Pilot', status: 'In Space' },
      { id: 2, name: 'Sam Rivera', role: 'Engineer', status: 'On Ground' },
    ],
    missions: [
      { id: 'M01', destination: 'Mars', status: 'Active' },
      { id: 'M02', destination: 'Moon', status: 'Completed' },
    ],
    resources: { oxygen: 85, fuel: 60 },
  });

  const updateResources = (newResources) => {
    setMissionData((prev) => ({
      ...prev,
      resources: { ...prev.resources, ...newResources },
    }));
  };

  // Value passed to consumers
  const value = { missionData, updateResources };

  return (
    <MissionContext.Provider value={value}>
      {children}
    </MissionContext.Provider>
  );
}

That’s how the React app created a context into which states could be stacked. But this API was not designed to manage states. To that end, it came to be used spontaneously, given all the costs of “prop drilling” already mentioned. Unfortunately, the use of context, although more efficient, created a number of performance problems for applications. Quite large portions of applications had to be rendered anew when states changed.

Development teams that tried this approach to solving the state management problem came up with several “crutch solutions” that made the problem less acute, but solving the problem this way still seemed completely ineffective. In the case of highly loaded applications, context was no longer a solution at all. With a high number of updates, if you have a lot of things that change frequently, the context renders each child of each item put into the context at each update.

A kind of milestone that showed that sooner or later special libraries would start appearing to solve the problem was Flux. This is an application architecture, which was proposed in 2014 by Facebook developers and which was supposed to help implement state management more efficiently. Instead of updating state values directly, the creators of this architecture proposed to send “Actions” via “Dispatchers” to “Stores”, where any component could receive them via “Views”.

PLACE FOR THE PICTURE

In 2015, Redux appeared, a library that became a solution for many React and Vue.js developers to the problem of state management and remains a leader to this day. Its developer, Dan Abramov decoded the name as “Reducers + Flux”. His innovation in the Flux architecture was that he replaced “Stores” and “Dispatchers” with first a few Reducers and then one, greatly simplifying the design.

There have been attempts to go further and make state management more economical in terms of application resources, more convenient and more maintainable from a code perspective. In late 2019, a new framework in this area – RTK became available to the developer community, and 2020 marked the arrival of Zustand.

But shortly before that, the creators of React itself responded to the formation around the issue of third-party libraries saying there were problems in React itself. By announcing and then introducing such functionality as React hooks into the core technology. The solution to the problem of getting actual states in different components and managing them became possible using the useState and useReducer methods. The syntax of this approach to the problem began to look like this:

import { useState, useReducer } from 'react';

// Reducer function for managing oxygen level state
const oxygenReducer = (state, action) => {
  switch (action.type) {
    case 'DECREASE':
      return Math.max(0, state - 10); // Decrease by 10%, minimum 0%
    case 'INCREASE':
      return Math.min(100, state + 10); // Increase by 10%, maximum 100%
    case 'RESET':
      return 100; // Reset to full oxygen
    default:
      return state;
  }
};

// Top-level component with both useState and useReducer examples
const MissionControl = () => {
  // useState version
  const [oxygenLevelState, setOxygenLevelState] = useState(100);

  // useReducer version
  const [oxygenLevelReducer, dispatch] = useReducer(oxygenReducer, 100);

  return (
    <div>
      <h1>Mission Control</h1>

      {/* useState Section */}
      <section>
        <h2>Using useState</h2>
        <p>Current Oxygen Level: {oxygenLevelState}%</p>
        <button onClick={() => setOxygenLevelState(Math.max(0, oxygenLevelState - 10))}>
          Simulate Oxygen Consumption (useState)
        </button>
        <AstronautTeam oxygenLevel={oxygenLevelState} />
      </section>

      {/* useReducer Section */}
      <section>
        <h2>Using useReducer</h2>
        <p>Current Oxygen Level: {oxygenLevelReducer}%</p>
        <button onClick={() => dispatch({ type: 'DECREASE' })}>
          Simulate Oxygen Consumption
        </button>
        <button onClick={() => dispatch({ type: 'INCREASE' })}>
          Replenish Oxygen
        </button>
        <button onClick={() => dispatch({ type: 'RESET' })}>
          Reset Oxygen
        </button>
        <AstronautTeam oxygenLevel={oxygenLevelReducer} />
      </section>
    </div>
  );
};

// This component doesn't use the oxygen level itself but passes it down (prop drilling)
const AstronautTeam = ({ oxygenLevel }) => (
  <div>
    <h3>Astronaut Team</h3>
    <p>Team is monitoring the mission...</p>
    <Astronaut oxygenLevel={oxygenLevel} />
  </div>
);

// The deepest component that uses the oxygen level
const Astronaut = ({ oxygenLevel }) => (
  <div>
    <h4>Astronaut Report</h4>
    <span style="font-size: 10pt; font-family: Consolas, sans-serif; color: rgb(173, 229, 252); background-color