Zustand vs React Query: The Smart Way to Manage React State

js

Zustand vs React Query: The Smart Way to Manage React State

Learn when to use Zustand for client state and React Query for server state to build scalable React apps with cleaner code and fewer bugs.

May 2, 2026

Zustand vs React Query: The Smart Way to Manage React State

I have been building React applications for a while now. And I have made a mess of my state management more than once. The turning point came when I had a dashboard with live updates, user preferences, modal toggles, and a search that fetched data from three different endpoints. Everything was in one Redux store. Every action felt like pulling a thread on a sweater. Debugging took forever because server state and UI state were tangled together like old Christmas lights.

That is when I discovered that not all state is created equal. You have server state — data from an API that needs fetching, caching, and refetching. And you have client state — things like “is the sidebar open?” or “what filter did the user select?”. Trying to manage both with the same tool is a recipe for pain. So I started using Zustand for client state and React Query for server state. Let me show you how this works in practice.

The Problem with a Single Store

Imagine you have a component that shows a list of products. You store the products in a global state. Then you add a button that opens a modal. You also store a boolean for that modal in the same state. Now every time you fetch new products, you have to dispatch an action, update a reducer, and maybe even clear some UI state. Your store becomes a dumpster fire.

Worse, you might accidentally cause unnecessary re-renders. If a piece of UI state changes, your product list might re-fetch. That is bad for performance. And when you have multiple developers working on the same store, conflicts happen.

How do you know which state belongs where? Ask yourself: does this data come from an API? If yes, it belongs to React Query. Does this data live only in the browser and affect how the UI looks or behaves? That is for Zustand.

The Separation of Concerns

Let me walk you through a real example. I was building a job board application. Users could filter jobs by location, category, and salary range. These filters are client state — they are only relevant for the current session and do not need to be persisted on the server. But the actual job listings come from an API. That is server state.

With Zustand, I created a tiny store just for filters:

import { create } from 'zustand';

const useFilterStore = create((set) => ({
  location: '',
  category: '',
  salaryMin: 0,
  salaryMax: 100000,
  setLocation: (loc) => set({ location: loc }),
  setCategory: (cat) => set({ category: cat }),
  setSalaryRange: (min, max) => set({ salaryMin: min, salaryMax: max }),
  resetFilters: () => set({ location: '', category: '', salaryMin: 0, salaryMax: 100000 }),
}));

Notice how simple it is. No actions, no reducers, no boilerplate. Just a function that gives you state and updaters.

Now for the server state. I used React Query to fetch jobs based on those filters:

import { useQuery } from '@tanstack/react-query';

function useJobs() {
  const { location, category, salaryMin, salaryMax } = useFilterStore();

  return useQuery({
    queryKey: ['jobs', { location, category, salaryMin, salaryMax }],
    queryFn: () => fetchJobsFromApi({ location, category, salaryMin, salaryMax }),
    // React Query handles caching, refetching, loading, and error states.
  });
}

When the user changes a filter in Zustand, the component re-renders, and the query key changes. React Query automatically refetches with the new parameters. But here is the magic: React Query caches previous results. If the user goes back to a previous filter combination, the data comes from cache instantly.

Why This Matters for Scalability

In a small application, you might not notice the difference. But as your app grows, this separation becomes a lifesaver. React Query gives you built-in deduplication — if two components request the same data, only one network call is made. It also provides stale-while-revalidate, background refetching on window focus, and pagination helpers.

Zustand keeps your client state tiny and focused. It does not need to worry about async operations. That means you can update a filter and the UI changes immediately without waiting for a fetch to complete.

But there is a subtlety: what if you need to trigger a refetch manually after a user performs an action, like submitting a form? React Query has invalidateQueries for that. You can call it inside a Zustand action or directly in a component.

import { useQueryClient } from '@tanstack/react-query';

function SubmitJobForm() {
  const queryClient = useQueryClient();

  const handleSubmit = async (formData) => {
    await saveJobToServer(formData);
    // After saving, invalidate the jobs list so it refetches
    queryClient.invalidateQueries({ queryKey: ['jobs'] });
  };
}

No need to store the saved job in Zustand. React Query handles the data lifecycle.

Personal Touch: The Moment It Clicked

I remember the day I finally understood this. I was debugging a slow page that had a complex form with dropdowns that fetched data from the server. Every time the user typed something, the dropdown options vanished because some UI state reset triggered a re-fetch. I spent hours chasing bugs. Then I refactored: moved all API calls to React Query, and all UI logic to Zustand. The page became fast, predictable, and easy to read.

A colleague asked me, “But what if I need both? Like a selected item that comes from the server and is then stored locally?” My answer: keep it simple. Store the selected item’s ID in Zustand, and let React Query fetch the full object when needed. Or if you must cache the full object, you can use React Query’s cache directly without duplicating in Zustand.

Common Pitfalls and How to Avoid Them

One mistake I see often: people try to store React Query’s data in Zustand. Do not do that. If you copy fetched data into Zustand, you lose automatic caching, background updates, and stale detection. You end up doing extra work and introducing bugs.

Another pitfall: using React Query for purely client state. Do not fetch a boolean from an API just because you think it should be persistent. Use localStorage or a simple Zustand persist middleware instead.

And never, ever put a second copy of the same data in two places. That is how bugs are born.

Conclusion

This approach changed how I build React apps. It made my code cleaner, my debugging faster, and my team happier. If you are tired of fighting with state management, try this: let React Query own everything that comes from a server, and let Zustand own everything that is purely local. Give your tools one job, and do it well.

If this article helped you see state management in a new light, drop a like, share it with a fellow developer who is still wrestling with a monolithic store, and leave a comment below telling me about your worst state management horror story. I read every single one.

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