Scalable React State Management with Zustand and React Query

js

Scalable React State Management with Zustand and React Query

Learn how Zustand and React Query simplify React state management by separating client and server state for scalable, bug-resistant apps.

Apr 16, 2026

Scalable React State Management with Zustand and React Query

I’ve spent years building React applications, and if there’s one thing that consistently trips up developers, it’s state management. It’s easy to get lost in a maze of reducers, contexts, and effects. Recently, I noticed a pattern in successful projects: they don’t treat all state the same. Instead, they separate client and server state. This realization led me to explore combining Zustand and React Query. Why? Because together, they offer a clear path to scalable apps without the usual headaches. If you’ve ever struggled with bloated stores or stale data bugs, this approach might change how you think about state. Let’s get started, and I encourage you to follow along—share your thoughts in the comments later.

State in React apps isn’t a monolith. Think about it: some data, like whether a sidebar is open, lives only in the browser. Other data, like user profiles, comes from a server and needs careful handling. Jumbling these together is a common mistake. I’ve seen codebases where a single Redux store holds everything, leading to complex selectors and unnecessary re-renders. It doesn’t have to be this way. What if you could split these concerns cleanly?

Enter Zustand. It’s a tiny library that handles client-side state with minimal fuss. You create a store with a simple function, and it updates components reactively. No providers to wrap, no boilerplate. For instance, managing a theme toggle is straightforward. Here’s a quick example:

import create from 'zustand';

const useThemeStore = create((set) => ({
  isDarkMode: false,
  toggleTheme: () => set((state) => ({ isDarkMode: !state.isDarkMode })),
}));

// In a component
function ThemeToggle() {
  const { isDarkMode, toggleTheme } = useThemeStore();
  return <button onClick={toggleTheme}>{isDarkMode ? 'Light' : 'Dark'}</button>;
}

This code sets up a store for UI state. It’s synchronous and local—perfect for things like modals, form inputs, or user preferences. But what about data from an API? That’s a different beast. Have you ever cached server responses in a client store and then dealt with outdated information?

That’s where React Query shines. It’s built for server state. Instead of manually fetching data and storing it, you define queries, and React Query handles caching, refetching, and synchronization. It treats server data as an external dependency, which makes sense. Why reinvent the wheel for data fetching? Here’s a basic query:

import { useQuery } from 'react-query';

function fetchUserData(userId) {
  return fetch(`/api/users/${userId}`).then(res => res.json());
}

function UserProfile({ userId }) {
  const { data, isLoading, error } = useQuery(['user', userId], () => fetchUserData(userId));
  
  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;
  
  return <div>Hello, {data.name}!</div>;
}

With React Query, you get background updates and cache management out of the box. No more manual loading states or error handling sprawl across components. But here’s a question: how do you combine this with Zustand without creating a mess?

The key is separation of concerns. Let Zustand manage client state and React Query manage server state. They can work side by side without interfering. In my projects, I use Zustand for things like filters or UI flags, while React Query handles all API data. This keeps stores lean and focused. Imagine a dashboard app: filters for data (client state) live in Zustand, and the chart data (server state) comes from React Query.

But what about when they need to interact? For example, a filter in Zustand might affect a query in React Query. This is where integration gets interesting. You can use Zustand to store filter values and then pass them to React Query queries. Here’s a practical example:

import create from 'zustand';
import { useQuery } from 'react-query';

// Zustand store for filters
const useFilterStore = create((set) => ({
  status: 'active',
  setStatus: (newStatus) => set({ status: newStatus }),
}));

// React Query based on filter
function fetchTasks(status) {
  return fetch(`/api/tasks?status=${status}`).then(res => res.json());
}

function TaskList() {
  const { status } = useFilterStore();
  const { data: tasks } = useQuery(['tasks', status], () => fetchTasks(status));
  
  return (
    <div>
      {/* Render tasks based on status */}
      {tasks?.map(task => <div key={task.id}>{task.name}</div>)}
    </div>
  );
}

This setup is clean. The filter state is in Zustand, and React Query uses it to fetch data. When the filter changes, React Query automatically refetches with the new parameter. No need to manually trigger fetches or manage cache invalidation. It’s reactive and efficient.

However, it’s not always this straightforward. Sometimes, you might be tempted to store server data in Zustand. Resist that urge. I’ve made this mistake before—it leads to duplicate state and sync issues. React Query is optimized for server data; let it do its job. Instead, use Zustand for derived state or UI interactions that depend on queries. For instance, you could store a selected item ID in Zustand and use React Query to fetch its details.

What does this mean for scalability? As apps grow, state management often becomes a bottleneck. With this pattern, each part has a single responsibility. New developers can onboard faster because the logic is decoupled. Debugging is easier too; you know where to look for issues. Server state problems? Check React Query. UI glitches? Look at Zustand. This separation reduces cognitive load.

Consider performance. React Query’s caching prevents unnecessary network requests, while Zustand’s minimal updates keep renders fast. Together, they avoid common pitfalls like over-fetching or stale UI. But how do you handle errors globally? React Query provides error states in queries, and Zustand can manage error UI states. You might use Zustand to show a notification when a query fails, for example.

Here’s a personal touch: in a recent e-commerce project, we used this combo. Zustand managed the shopping cart (client state), and React Query handled product listings and user data. The result? A responsive app with fewer bugs. When we needed to add new features, like wishlists, it was simple—just extend the stores or queries without refactoring everything.

Code maintenance improves too. With short, focused functions, testing becomes straightforward. You can mock Zustand stores or React Query hooks independently. This modularity is a game-changer for team workflows. Ever spent hours tracing a state update through nested reducers? This approach cuts that complexity.

Now, let’s address a potential concern: what about shared state that’s neither purely client nor server? For example, user authentication tokens. I recommend keeping tokens in a secure place like HTTP-only cookies and letting React Query manage auth-related queries. Use Zustand for login modal visibility or user preferences. This keeps sensitive data out of client stores.

To wrap up, integrating Zustand and React Query isn’t just about using two libraries—it’s about adopting a mindset. Separate your state by concern, and let each tool excel. This leads to cleaner code, better performance, and happier developers. Start small: try it in a new component or refactor an existing one. You might be surprised how much simpler things become.

I hope this guide helps you build more scalable React applications. If you found it useful, give it a like, share it with your team, and drop a comment below with your experiences or questions. Let’s keep the conversation going—state management doesn’t have to be a chore.

As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!

📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!

Our Creations

Be sure to check out our creations:

We are on Medium

Share: Facebook Twitter Reddit LinkedIn WhatsApp Telegram Pinterest Email Instagram

js