Introduction
State management is one of the cornerstones of React applications. As your app grows in complexity, managing the state effi...
For further actions, you may consider blocking this person and/or reporting abuse
What about hydration issues?
Excellent question, Thomas Burleson!
Hydration issues can arise when the store isn’t handled properly, particularly if it’s initialized and used differently on the client and server. From my experience with Zustand, I’ve never encountered hydration issues caused by Zustand itself. This is because I separate my store implementations on the server side and avoid initializing them directly on the client.
While I don’t have personal experience with hydration issues caused by Zustand, I’d recommend keeping your stores in a dedicated folder, such as
/src/storeor another path that fits your project structure. This practice helps ensure there’s no conflicting state between the client and server.Thanks for bringing this up!
Zustand makes state management in React & Next.js effortless, with minimal boilerplate and maximum performance. Perfect for modern web apps! 🚀
Absolutely! Glad to hear you found my article useful 🙂
Why persistent, across pages? it could be fetch in source path. Like dark / light theme flag vale.
Hey Anupam Maurya!
The source path fetch is less advisable as things can get quite messy when working with many different variables within the state. The state is persistent and should be that way to provide the user with their selected theme even after leaving the page and returning back to it.
In any case, my example was only to show the option to persist the state across multiple pages and keep it even if the user has quit the page instance. In real cases of implementing dark mode and light mode, I would advise using the next-themes package instead of a persistent state.
Thanks for your question!
When taking a look at the official docs they recommend to initialize the store per request using a provider zustand.docs.pmnd.rs/guides/nextjs
How are you getting around this issue?
Great question, Andreas!
The provider-localized store recommended in the docs is ideal for isolating state per request or page instance, ensuring changes don’t carry over unintentionally. This works well for cases like guest-mode demos, where state resets on each session or page.
However, it depends on your use case. In my project CodeLib, I needed a global state to manage data fetched dynamically from an external SDK client (which was used together with a search functionality for all of the user's data). This state had to persist across pages to provide seamless access to code snippets. A provider setup wouldn’t work here, as it ties state to a single page.
Provider-localized state is perfect for temporary data, while global state is better for persistent needs like user authentication or shared resources. Both have their place—choose based on your app’s requirements.
Let me know if you have anymore questions!
Looks pretty good!
Thank you so much! Stay tuned for an interesting article tomorrow as well :)
Ever since I got introduced to Zustand about 2 years ago, it has since being my state management library in all my projects.
I love Zustand