State management in React can get messy. I’ve seen it too many times. A simple useState balloons into a mess of useContext and reducers. The tipping point for me was a project where a single global store held API data, UI flags, and user inputs. Updating a simple menu toggle triggered unnecessary re-renders for a massive list of fetched items. The application felt slow, and development became a chore. That’s when I realized we were using the wrong tool for the job. We were treating all state as if it were the same.
This led me to a powerful idea: what if we separated our concerns from the start? What if server state and client state were handled by specialized tools? This is the core of integrating Zustand and React Query.
Client state is the state of your application’s interface. It includes things like whether a sidebar is open, the current theme, or form values before submission. This state is synchronous, predictable, and lives entirely in the browser.
Server state is different. It’s data that comes from an external source—an API, a database. It’s asynchronous, shared, and can become outdated. Think of a user profile, a list of products, or live notifications. Managing this with a regular state library means manually handling loading states, errors, caching, and updates.
So, what happens when you use a client-state tool for server state? You reinvent the wheel, poorly. You write useEffect hooks for fetching, create custom caches, and manage complex update logic. Your components become cluttered. This is the problem I was trying to solve.
Zustand is my go-to for client state. It’s tiny and straightforward. You create a store with minimal code. There’s no Provider to wrap your app in, no complex setup. You get a hook, and you use it. It feels like using useState, but shared across components.
Here’s a store for a simple UI:
import { create } from 'zustand';
const useUIStore = create((set) => ({
isDarkMode: false,
sidebarOpen: true,
toggleDarkMode: () => set((state) => ({ isDarkMode: !state.isDarkMode })),
closeSidebar: () => set({ sidebarOpen: false }),
}));
// In a component
function Header() {
const { isDarkMode, toggleDarkMode } = useUIStore();
return <button onClick={toggleDarkMode}>Toggle {isDarkMode ? 'Light' : 'Dark'}</button>;
}It’s clean. Components only subscribe to the state they need. This is perfect for transient UI state. But what about data from an API?
This is where React Query enters the picture. It is not a state manager in the traditional sense. Think of it as a sophisticated cache for your asynchronous data. It fetches, caches, synchronizes, and updates your server state. It handles the hard parts: background refetching, cache invalidation, and pagination.
Here’s a basic query:
import { useQuery } from '@tanstack/react-query';
function UserProfile({ userId }) {
const { data, isLoading, error } = useQuery({
queryKey: ['user', userId],
queryFn: () => fetch(`/api/users/${userId}`).then(res => res.json())
});
if (isLoading) return <div>Loading...</div>;
if (error) return <div>Error: {error.message}</div>;
return <div>Hello, {data.name}</div>;
}React Query manages the data, isLoading, and error state. You don’t put this in a Zustand store. The question is, how do they work together?
The integration is not about making them talk to each other directly. It’s about establishing a clear boundary. React Query is the source of truth for server state. Zustand is the source of truth for client state. They operate in separate layers.
Consider a complex scenario: a dashboard with user settings (client state) and a live data feed (server state). The feed needs to auto-refresh, but the user can pause it with a button. Can you see where the boundary lies?
The “is paused” toggle is client state—a perfect fit for Zustand. The live feed data is server state, managed by React Query. The Zustand store can hold a simple boolean that the React Query configuration can read to decide whether to refetch.
// Zustand store for the dashboard control
const useDashboardStore = create((set) => ({
isFeedPaused: false,
toggleFeedPause: () => set((state) => ({ isFeedPaused: !state.isFeedPaused })),
}));
// React Query hook for the live feed
function useLiveFeedData() {
const isFeedPaused = useDashboardStore((state) => state.isFeedPaused);
return useQuery({
queryKey: ['liveFeed'],
queryFn: fetchLiveFeed,
refetchInterval: isFeedPaused ? false : 5000, // Pause refetching when user toggles
});
}The integration is seamless. The query reads from the client store, but it doesn’t write to it. The state types remain pure. This separation is the key to scalability. Your logic becomes easier to follow. You know exactly where to look when a bug appears: is it in the UI logic (Zustand) or the data-fetching logic (React Query)?
Testing improves dramatically. You can test your Zustand stores in isolation, mocking no APIs. You can test your React Query hooks with tools like the QueryClient, without rendering complex UI trees.
Performance sees a direct benefit. Since React Query handles caching, identical queries across components don’t cause duplicate network requests. Zustand ensures that a change in a UI setting, like a filter, only re-renders the components subscribed to that specific piece of state.
Are you currently mixing fetch logic with your UI state? Imagine deleting all that useEffect and useState boilerplate for loading and error states. That’s the immediate relief this pattern provides.
In practice, start by auditing your current state. Ask for each piece: “Does this come from the server?” If yes, it’s a candidate for React Query. “Is this purely about how the interface behaves?” If yes, Zustand is your tool. This simple decision tree will clean up your architecture.
The combination gives you resilience. Network requests fail, but your UI toggles will still work instantly because they are independent. The user experience feels more robust.
I encourage you to try this separation in your next feature. Start small. Move one API fetch to React Query and one UI control to Zustand. Feel the difference in clarity. You might find, as I did, that your application becomes not just easier to manage, but more enjoyable to build.
What has been your biggest challenge with state management so far? Let me know in the comments. If this approach to separating concerns makes sense, please share this article with a teammate who might be wrestling with the same problems.
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:
Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
