State Management Architecture. Part 2. From RTK Query to Zustand

This article is the second part of a series of publications by Hiveon’s leading frontend engineer Anton An about the best frameworks for state-management. You can read about the evolution of state-management, traditional Redux and RTK Toolkit, which develops its approaches, in the first part of the article.

In state-management, traditional Redux is considered obsolete. Modern alternatives include RTK Query and Zustand, and frameworks can be used together to complement each other in your project.

RTK Query

RTK Query focuses on synchronizing application state with server data, making it an excellent tool for API-driven projects. It provides automatic caching to minimize redundant requests, request deduplication, and built-in polling intervals for periodic data updates—features that streamline server state management.

However, effective cache management is critical. Incorrectly configured cache invalidation or tag relationships can result in stale data or unnecessary re-fetching, impacting performance. For instance, subtle changes in input parameters might trigger excessive re-renders if tags are not carefully defined. Thorough planning and testing are required to leverage RTK Query’s full potential.

// missionApi.js (API Slice)
import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

// Define the mission API slice
export const missionApi = createApi({
  reducerPath: 'missionApi',
  baseQuery: fetchBaseQuery({ baseUrl: 'https://api.space-mission.example.com/' }), // Hypothetical API
  tagTypes: ['Missions', 'Resources'], // Tags for cache invalidation
  endpoints: (builder) => ({
    // Fetch all active missions
    getMissions: builder.query({
      query: () => 'missions',
      providesTags: ['Missions'], // Tag for caching missions
    }),
    // Fetch resource levels (oxygen, fuel)
    getResources: builder.query({
      query: () => 'resources',
      providesTags: ['Resources'], // Tag for caching resources
      // Polling every 30 seconds to simulate real-time updates
      pollingInterval: 30000,
    }),
    // Update mission status (e.g., mark as completed)
    updateMissionStatus: builder.mutation({
      query: ({ id, status }) => ({
        url: `missions/${id}`,
        method: 'PATCH',
        body: { status },
      }),
      invalidatesTags: ['Missions'], // Invalidate mission cache on update
    }),
  }),
});

// Export hooks for usage in components
export const {
  useGetMissionsQuery,
  useGetResourcesQuery,
  useUpdateMissionStatusMutation,
} = missionApi;

// store.js (Store Configuration)
import { configureStore } from '@reduxjs/toolkit';
import { missionApi } from './missionApi';

// Configure the store with RTK Query reducer
const store = configureStore({
  reducer: {
    [missionApi.reducerPath]: missionApi.reducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(missionApi.middleware),
});

export default store;

// MissionDashboard.js (Component)
import React from 'react';
import {
  useGetMissionsQuery,
  useGetResourcesQuery,
  useUpdateMissionStatusMutation,
} from './missionApi';

export function MissionDashboard() {
  // Fetch missions with automatic caching
  const {
    data: missions,
    error: missionsError,
    isLoading: missionsLoading,
  } = useGetMissionsQuery();

  // Fetch resources with polling
  const {
    data: resources,
    error: resourcesError,
    isLoading: resourcesLoading,
  } = useGetResourcesQuery();

  // Mutation to update mission status
  const [updateMissionStatus] = useUpdateMissionStatusMutation();

  if (missionsLoading || resourcesLoading) return <p>Loading mission data...</p>;
  if (missionsError || resourcesError)
    return <p>Error fetching data: {missionsError?.message || resourcesError?.message}</p>;

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

      {/* Missions Section */}
      <section>
        <h2>Active Missions</h2>
        <ul>
          {missions.map((mission) => (
            <li key={mission.id}>
              {mission.destination} - {mission.status}
              {mission.status === 'Active' && (
                <button
                  onClick={() =>
                    updateMissionStatus({ id: mission.id, status: 'Completed' })
                  }
                >
                  Mark as Completed
                </button>
              )}
            </li>
          ))}
        </ul>
      </section>

      {/* Resources Section */}
      <section>
        <h2>Resource Levels (Updated every 30s)</h2>
        <p>Oxygen: {resources.oxygen}%</p>
        <p>Fuel: {resources.fuel}%</p>
      </section>
    </div>
  );
}

// App.js (Main App)
import React from 'react';
import { Provider } from 'react-redux';
import store from './store';
import { MissionDashboard } from './MissionDashboard';

function App() {
  return (
    <Provider store={store}>
      <MissionDashboard />
    </Provider>
  );
}

export default App;

• missionApi: Defines endpoints for fetching missions (getMissions), resources (getResources), and updating mission status (updateMissionStatus).
• Caching: providesTags ensures data is cached under ‘Missions’ and ‘Resources’. The updateMissionStatus mutation invalidates the ‘Missions’ tag, triggering a refetch.
• Polling: getResources uses a 30-second pollingInterval to simulate real-time resource monitoring.

This tool is best suited for applications where server data is a primary concern, as it excels at managing the client-side cache of that data, handling the fetching, synchronization, and updates automatically. For purely local state needs, Redux Toolkit alone may suffice.

RTK Query Overview:

• Primary Role: Managing server state in data-intensive applications.
• Advantages: Efficient caching, deduplication, and polling support.
• Potential Issues: Cache configuration demands precision to avoid inconsistencies.

Next, we turn to Zustand, a contrasting approach that prioritizes simplicity over structure.

Zustand

Zustand offers a lightweight alternative to the Redux ecosystem, appealing to developers who need global state management without extensive overhead. Its minimal API enables rapid state setup—ideal for small libraries or performance-sensitive components where a full Redux implementation would be excessive.

This simplicity comes with trade-offs. Zustand lacks the rigid structure of Redux, requiring disciplined practices to maintain consistency in larger applications. Additionally, it offers no native support for complex asynchronous workflows, leaving developers to implement custom solutions as needed.

For projects prioritizing speed and minimalism, Zustand is highly effective. Its flexibility makes it a compelling choice when the complexity of Redux outweighs its benefits.

When it comes to syntax, Zustand is impressively more laconic than the same RTK library when writing code that handles passing states to components. Here’s an example of Zustand code implementing the astronaut status management similar to our Traditional Redux example:

// missionStore.js (Zustand Store)
import { create } from 'zustand';

// Create a Zustand store for mission data
const useMissionStore = create((set) => ({
  astronauts: [
    { id: 1, name: 'Alex Carter', status: 'In Space' },
    { id: 2, name: 'Sam Rivera', status: 'On Ground' },
  ],
  toggleAstronautStatus: (id) =>
    set((state) => ({
      astronauts: state.astronauts.map((astronaut) =>
        astronaut.id === id
          ? {
              ...astronaut,
              status: astronaut.status === 'In Space' ? 'On Ground' : 'In Space',
            }
          : astronaut
      ),
    })),
}));

export default useMissionStore;

// MissionControl.js (Component with Zustand)
import React from 'react';
import useMissionStore from './missionStore';

export function MissionControl() {
  // Access state and actions directly from the store
  const astronauts = useMissionStore((state) => state.astronauts);
  const toggleAstronautStatus = useMissionStore((state) => state.toggleAstronautStatus);

  return (
    <div>
      <h1>Space Mission Control (Zustand)</h1>
      <h2>Astronaut Status</h2>
      <ul>
        {astronauts.map((astronaut) => (
          <li key={astronaut.id}>
            {astronaut.name} - {astronaut.status}
            <button onClick={() => toggleAstronautStatus(astronaut.id)}>
              Toggle Status
            </button>
</li>
        ))}
      </ul>
    </div>
  );
}

// App.js (Main App with Zustand)
import React from 'react';
import { MissionControl } from './MissionControl';

function App() {
  return <MissionControl />;
}

export default App;

• Setup: A single file (missionStore.js) with create defines the store. No reducers or middleware needed.
• Usage: The useMissionStore hook provides direct access to state (astronauts) and actions (toggleAstronautStatus) without extra boilerplate.
• Theme: Manages astronaut statuses (e.g., “In Space” or “On Ground”), fitting the mission control theme.
• Pros: Lightweight, minimal API, no provider wrapper required.
• Trade-offs: No built-in structure for complex async flows (e.g., API calls would need custom logic).

As you can see Zustand is ideal for simple state needs in our space mission context. However, as noted, its lack of rigid structure means developers must enforce discipline in larger apps, and async tasks (e.g., fetching astronaut data) would need manual handling—unlike RTK’s ecosystem support.

Zustand Essentials:

• Best Scenarios: Simple global state or performance-critical components.
• Benefits: Lightweight design and efficient updates.
• Limitations: Requires careful management in large projects; async support is minimal: asynchronous logic is often handled by placing async functions directly within the store or by using Zustand’s middleware support if needed.

To clarify these distinctions, let’s compare the options directly.

Comparative Analysis

The table below consolidates key attributes—performance, scalability, learning curve, ecosystem support, and challenges—based on practical observations. It aims to assist in identifying the most suitable tool for your project.

Building on this comparison, consider how these tools might work together.

Combining Approaches

In some cases, a hybrid strategy can maximize the strengths of multiple tools. Pairing Redux Toolkit with RTK Query, for instance, provides robust UI state management alongside optimized server data handling within the Redux ecosystem. Adding Zustand for specific, performance-critical components introduces localized efficiency without redundant complexity.

Integration poses challenges, however. While Redux Toolkit and RTK Query align seamlessly, Zustand’s distinct paradigm requires careful consideration for synchronization. While React’s useSyncExternalStore primitive provides a foundation for integrating external stores, connecting disparate state managers like Redux and Zustand smoothly often relies on well-designed application architecture or potentially specific adapter libraries. Without deliberate design, this can lead to inefficiencies, such as redundant updates. Clear boundaries and testing are essential to ensure a cohesive architecture.

Finally, let’s distill this into a practical framework for decision-making.

Checklist: How to choose the right framework for your project situation?

The following considerations can guide your choice of state management solution, tailored to your project’s needs:

• How big is your project going to be? Large, intricate applications often benefit from the structure provided by the Redux ecosystem (typically via Redux Toolkit); smaller efforts might lean toward Zustand.
• What states will need to be managed? Focus on UI state suggests RTK or Zustand; server synchronization points to RTK Query.
• What kind of performance are you willing to put up with? Evaluate memoization and caching needs; Zustand excels in lightweight contexts.
• What is the expertise of the development team? Familiarity with Redux supports RTK adoption; simpler tools suit less experienced teams.
• What integrations are you planning to do? Combining tools requires strategic state synchronization to avoid overhead.

These questions provide a starting point for aligning your choice with project demands and team capabilities.

Conclusion

Choosing a state management solution requires balancing complexity, performance, and practicality. Traditional Redux offers unmatched control for intricate applications, though its verbosity can be a hurdle. Redux Toolkit refines this approach, delivering efficiency and clarity for modern needs. RTK Query excels in server-state scenarios, provided cache management is precise. Zustand, meanwhile, provides a nimble alternative for simpler or performance-driven requirements.

A combined approach can leverage these strengths, but demands thoughtful integration. By assessing your project’s scope, state needs, and team expertise—guided by the framework above—you can select a strategy that ensures scalability and maintainability tailored to your goals.