Using Zustand in React Server Components - misguided misinformation and misuse?

[ADTC]

PSA: There's no such thing as state on server.

It's unwise to do anything that assumes there is.

---

I feel like there's a lot of people who believe we can use Zustand to add state management to React Server Components which are basically stateless. See this Medium article, and this highly popular YouTube video (UPDATE: This video is now private by request of community.). (Other state management systems fail in RSC because they use the useContext hook, which Zustand does not.)

But in my testing, it looks like it doesn't work as intended and it's highly misleading. In fact, this kind of misuse to add "state management" on RSC can introduce bugs that are very strange and hard to debug. See this comment, for example:

There is a bit of an invisible risk with using Zustand + Next that I've run into before. If you ever manage to modify state on the server, that same state will be re-served to every user for the life of your Lambda (or the current server thread if you're just using a box, because Next will spin up multiple threads). This happened to me once because I had a Zustand store which captured the error state which could be triggered on the render of an ErrorBoundary which does fire on the server. So I created a case where if someone hit an invalid route (like 400 or 401, not just a 404), then different users would recieve seemingly random error notifications on new page loads. And because it only happened on certain threads under certain conditions, it was incredibly difficult to track down.

This is why, if you can, I would recommend that you wrap your Zustand store in context if you're using Next or Remix. Zustand has a flow for this described under the "React context" section in their documentation. Obviously this pattern unsolves your solution for RSC/Next@13 but I think it's worth considering.

And, as per my own comment here: https://medium.com/@send2adtc/this-will-not-work-correctly-server-side-although-it-appears-to-work-5bac595f5131

This will NOT work correctly server-side, although it appears to work. In fact, it will cause your data to LEAK!

If your website has pages behind authentication, try this: Put something that's only accessible by authentication into a server-side Zustand store. Render it into a server-side component in a server-rendered page. Try accessing this page via two different users. If you put something specific to user 1, then load the page for user 2, you'll see that the data from user 1 has now leaked into the page shown for user 2.

Server-side components are meant to be stateless, and if you use Zustand as a hack to bring state into server, it's just going to maintain a global state that's shared between ALL authenticated users. If you have a thousand users, ALL of them will see what the last user put in the "state" inside server.

Note: You don’t need to have a user authentication system in your project to reproduce this. You can just have a simple way to store a piece of text you entered in the Zustand store (for example using searchParams), then a simple page that displays this data. (All of it should be server-side.) Then run this across multiple browsers, or even multiple devices and networks. Store a unique text on one client instance, then load the page everywhere. You should see it in all client instances. Store another unique text in another instance, and refresh all instances to see the new text.

Would the developers of Zustand care to clarify? If this is indeed incorrect usage, I highly recommend warning users about it, especially here in the Readme, and maybe even adding some kind of warning emission system within Zustand if it can detect being used on RSC.

[dai-shi]

Thanks for the heads-up.
What should be warned is using Zustand on the server, regardless of RSC or SSR.
We should use React Context to isolate states.
It's been an issue since back in the old days. #182 (then zustand/context is introduced in v3, which is deprecated in v4. It's now recommended to use React Context.)
Yeah, I think docs should be clear about it. Maybe, docs/guide/nextjs.md, or something?

[ADTC]

Yeah, people are misusing Zustand on server, thinking it works (because it looks like it does), deploying it to production and later finding out what a horrible idea it was. Lol. At least I had the foresight to immediately test what would happen if two users were accessing at the same time...

Please, let's add prominent warnings to deter people from doing so.

Is there a way for Zustand to detect usage on server at runtime and throw error that it should be used in client only?

[dai-shi]

Can you open a PR and draft docs/guide/nextjs.md?

The runtime solution would be difficult, because it's not 100% misusage and often this kind of detection isn't perfect.

[ADTC]

To be clear, this is not really specific to Next.js, but rather for React Server Components, although most people talk about RSC in the context of Nextjs apps.

Also, for now I think a warning in the main readme could suffice. Hence I opened PR #2202

[dai-shi]

Yes, it's not specific to Next.js, but 99% of cases would be Next.js use case, for now.

[ADTC]

Okay. What do you think of the PR? Should I also mention Next.js in the warning? Feel free to edit it or suggest changes.

[StefanBurscher]

I debugged like 8 hours to find out why, whenever someone logs in to my app, all the users (even in incognito) on the first render see the last logged user.

I first thought it was a next caching issue... The issue is indeed with the usage of Zustand on the react server component. I watched the YouTube video about how to share the state between server and client components and thought about the solution. Now I get the issue and thanks for writing about it.

I hope there won't be many cases like mine, but I guess the video should be deleted.

I highly recommend you not use Zustand for the purpose of sharing state between server and client components, because it will be cached until you do a rebuild or replace the edge and that's in most cases not wanted behavior.

[ADTC]

Good news! I managed to reach out to the video channel owner, and he has been kind enough to make the video private now.

[YoavGrosman]

What is the recommended way to use Zustand with RSC?
Say I have a a store with user and a list of products, that some should be hidden if the user isn't logged in. How would I update the store state while avoiding data leak?

[dbritto-dev]

Everything should run on the client, you can instantiate a store with data from the server but that's it

[ADTC]

@YoavGrosman your question may not have enough information. But based on what I understand, I don't think you need any kind of state for hiding some products based on user presence. You can simply check the condition of the user presence and just render or don't render the product. Basic example: {!!user && <Product ... />}

[der-daniel]

@dbritto-dev what does this mean? How do you pass server data from a server component into zustand?

[ADTC]

How do you pass server data from a server component into zustand?

As props to client components, which can use it directly or put it in the client-side state (useState, useContext, Zustand, etc.).

Remember: Servers are stateless.

[dai-shi]

There's some misconception. The Zustand store is a global variable (or also known as a module state), which is why you don't need Provider. The issue/behavior is known in SSR, but it seems to get bigger with RSC. Maybe we can add a DEV-only warning for RSC.

[davidebriscese]

Is it safe and recommended to set the client-side state from server like this?

/app/page.tsx:

/* Server side component */
import { ClientSideStateManager } from "@/src/store/client-test";
export default async function Page() {
  const data = await fetch(...)
  return (
    <>
      <ClientSideStateManager state={data} />
      <ClientComponent />
    </>
  )
}

/src/store.tsx:

/* Client side component */
'use client'
import { useEffect } from 'react'
import { myStore } from './my-store'
export function ClientSideStateManager({ state }: any) {
  useEffect(() => {
    myStore.setState(state)
  }, [state])
  return <></>
}

[dai-shi]

I somehow thought this was about subsequent updates, not an initial hydration from SSR.

If it's initial store creation, you can provide server state.

const myStore = create((set) => ({
  foo: 'bar',
  ...stateFromServer,
  setFoo: () => { /* ... */ },
}));

But, this requires React Context, so useEffect might be easier. (Still, you can avoid the second render if the state is the same with the technique above.)

Theoretically, setState is allowed if it's done before used by any components (otherwise, you get hydration mismatch)
#2277 added new getInitialState which may or may not solve this case.
#2298 is WIP docs, so feedback is welcome there.

This might not be answering to your question. Feel free to have follow-up questions. Do you want to avoid useEffect, or double rendering?

[phungleson]

Thanks for the explanation, no worries, yeah the whole SSR and RSC makes things quite difficult to understand and implement state management.

Perhaps, we can some examples to let people know what is the best practice to use zustand with different frameworks? If you are ok, I can create an example with remix?

[phungleson]

Ah ok I read #2277, yeah not sure if it solve the issue, but maybe I just wait for #2298 to complete to understand it better.

[ADTC]

the whole SSR and RSC makes things quite difficult to understand and implement state management

I think the simple mantra is, there's no such thing as state on server, and we should not do anything that assumes there is.

[phungleson]

Righto thanks for confirmation, save me from headache last few days.

It would still be nice to have examples to tell people how to setup zustand strictly for client side usage with server frameworks like Nextjs and Remix, people are prone to errors, especially with global/singleton things.

[chiralium]

Is there anyone checked, that second parameter true in the setState-call fix the problem? The second parameter indicate to merge a store or replace it

[dai-shi]

It replaces the store state, but if the store is global, it's global.

[sandeepbfnp]

one solution is that fetching API in server component and passing it to client component and then to zustand store, and we use the API response directly in the server components. only issue is here the hydration of server and client state

[ADTC]

the hydration of server and client state

As far as I know, there's no such thing as "state" on server. A lot of us misunderstood that there is, because it appeared so. It was just a mirage.

Can you elaborate what you mean by "server state"?

[sandeepbfnp]

right.. got it now...
Do you have any solution or information from zustand?

[ADTC]

Yes. It's an anti-pattern. If you're trying to have state in server, rethink your code. It should be possible to do what you want without the flawed idea of "server state".

[Ruffeng]

If someone is looking to implement Zustand with RSC and they need to populate the initial state with some info from the server (like initial data from a fetch or so), the best solution is to wrap the client component with a useContext provider and use the new helper createStore. Here are the necessary articles to do so:
Create Store: https://docs.pmnd.rs/zustand/guides/initialize-state-with-props
Create context: https://docs.pmnd.rs/zustand/previous-versions/zustand-v3-create-context#migration

With this you can set a state the result of some fetch did in the server component and see the results immediately in your page.

As some people said, it is not a good practice to try to populate a store from server components and pass that store into client.

[twelve17]

Is this guide on the zustand site providing misguided information too? I'm moving an app to nextjs and am running into difficulties in how I would go about migrating the zustand integration.

https://docs.pmnd.rs/zustand/guides/nextjs

[dbritto-dev]

Is this guide on the zustand site providing misguided information too? I'm moving an app to nextjs and am running into difficulties in how I would go about migrating the zustand integration.

https://docs.pmnd.rs/zustand/guides/nextjs

@twelve17 what you mean with "misguided information? Would you mind opening a discussion?

[ADTC]

@twelve17 it has the following text:

React Server Components should not read from or write to the store - RSCs cannot use hooks or context. They aren't meant to be stateful. Having an RSC read from or write values to a global store violates the architecture of Next.js.

[Ruffeng]

@ADTC:

if (!storeRef.current) {
createInitialBearsStore(initialBears)
}
I believe you can just directly call createStore here, and avoid having state.ts file. See this example.

Of course you can do that, but this will easily get out of control when you have like 20 properties + 20 setters.

return createStore((set) => ({
// Othere pieces of state
...initialData
}))
The parameter set is unused.

Remember that this is just an example because you ask me :) I assume you will use set at some point in your state. If you wouldn't need the set method at all, I do not recommend to use then zustand because you would only need a read-only value and since it is wrapping already with a useContext, you can store directly the value as a useRef.

---

I am quite disappointed with the fact that you wanted an example to understand the ideas that I explained above, I take some time to prepare it and show it to you, and I only get back a kind of code review.

[ADTC]

@Ruffeng I appreciate your example, and I apologize for how my comment came across. Thanks for the clarifications.

[twelve17]

Is this guide on the zustand site providing misguided information too? I'm moving an app to nextjs and am running into difficulties in how I would go about migrating the zustand integration.
https://docs.pmnd.rs/zustand/guides/nextjs

@twelve17 what you mean with "misguided information? Would you mind opening a discussion?

I am referring to the title of this GH issue--meaning is it misguided in the same way that the OP has stated.

[twelve17]

I'm also just now realizing that the guide I linked to is probably the exact guide in this comment:

Hi peeps, we added recently a guide about nextjs and we improved the search tool too

I had not realized it initially, my mistake.

[twelve17]

@twelve17 it has the following text:

React Server Components should not read from or write to the store - RSCs cannot use hooks or context. They aren't meant to be stateful. Having an RSC read from or write values to a global store violates the architecture of Next.js.

@ADTC thanks for pointing this out. I suppose I'll want to put some guards on our store implementation to throw an error if there is an attempt to write to the store in a server component. That would probably be the best way to prevent opening a can of worms to cross-request data leakage.

[ADTC]

There are no guards. You just have to know what's what.

[mhfaust]

Several have recommended wrapping the store in a provider. From my past experience, I believe this diminishes the efficiency of referencing the store as a global variable by causing more re-renders. Have others had that experience?

Question: would, say, wrapping selectors in an HOF to throw errors when they are called server-side be a good preventative?
I'm going to give that a try.

[ADTC]

Show code?

[ben519]

I'm confused why the recommended approach is to use a context provider as opposed to passing the data from server component to client component and then setting the store there (as suggested by @davidebriscese)?

Thought the whole point of Zustand was to avoid using context providers.. Can anyone enlighten me?

[dbritto-dev]

@ben519 well there's two things there: one passing data from server components to client components, and second using a global store. There's no issue with passing data from server components to client components. What is not recommend is using global stores in context of servers (SSR, SSG, etc).

[ADTC]

@ben519 my recommendation is to do what befits your use case. Context providers serve a similar function to passing props, but help avoid excessive prop-drilling. If your prop drilling is shallow enough, you don't really need a context provider.

[alexomon018]

In my project, I encountered some confusion when using context providers alongside Zustand. Here's the approach I took:

I referred to the Zustand documentation on persisting store data, particularly the section about skipHydration (https://docs.pmnd.rs/zustand/integrations/persisting-store-data#skiphydration).

Steps I Followed:
I used the skipHydration property to control when hydration occurs. I then set skipHydration to true. I created a client component that requires the store state. Within the client component, I used the rehydrate function call inside a useEffect hook to handle the hydration process.

useEffect(() => { useAssetStore.persist.rehydrate(); setHasHydrated(true); }, []);

My question here is am I not seeing something wrong with this approach? Because it is currently working great but I want to be sure that I am not missing something. What do you think?

[dbritto-dev]

@alexomon018 useAssetStore.persist.rehydrate() should be enough

[alexomon018]

@dbritto-dev Thanks for the quick response! Really appreciate it

[raythurnvoid]

I've been reading how to use Zustand with SSR and seems quite complicated, why can't I just do what I normally do with the create function to create the hook, but instead of being defined in a module I do it in a component and then I make the hook available via context?

The use of createStore seems very unnecessary and only complicates everything.

[dai-shi]

Because on the server the module is shared across session (like users).

[alexomon018]

And you can potentially share the accessToken between users, allowing them to see each other's data and inadvertently create that wonderful experience by accident.

[raythurnvoid]

Not if you define the store in a component and serve it with context, am I missing something?

I mean this is the same thing I do in Vue and svelte, when a server is involved just declare global stuff In a component and serve with context.

[dbritto-dev]

@raythurnvoid yeah, you are missing that those stores defined at component level are not global stores.

[raythurnvoid]

The facto they are since I would have a root component (it can be a Layout in remix/nextjs) and every component underneath has to use the root context to access the hooks generated with create

[0x-Avant-Garde]

So from what I've gathered, it's relatively safe albeit a bit inefficient to make sensitive API calls in RSCs and pass the results to a useEffect() in a Client Component (in theory one that doesn't do anything other than update the Store) and plop that someone near the root of the closest RSC?

I'm a bit confused why context would be needed here if you were updating a global store and parsed user specific info in the store itself (aka products[user] pattern).

[dbritto-dev]

@0x-Avant-Garde you said it, global stores, but on nextjs you shouldn't use global stores we mentioned that in our nextjs guide but seems people keeps missing the docs and I wonder why

[0x-Avant-Garde]

Fair point. I've used Zustand on Next since like next 8 but things got really messy in 13+. I'll admit I haven't read much since then as I essentially gave up.

I meant global as more Client Side global but I'll check your guide to see about non-global stores, thanks!

[thiporia]

I understand why it's like useShallow.

[malixswoop]

This seems straightforward:
https://medium.com/@mak-dev/zustand-with-next-js-14-server-components-da9c191b73df

[dai-shi]

I was hoping this is an acceptable pattern, but at this point, it's said that "server actions" are not for data fetching.

[ADTC]

This is practically the same as React.Context.

it's said that "server actions" are not for data fetching.

Who said that? You can use it for absolutely anything!

[dai-shi]

https://react.dev/reference/rsc/use-server

Server Actions are designed for mutations that update server-side state; they are not recommended for data fetching. Accordingly, frameworks implementing Server Actions typically process one action at a time and do not have a way to cache the return value.

[dannobytes]

I'm working on this exact issue as we speak. I agree with some people here, that a huge motivator to switching to Zustand stores was to avoid using React contexts to broadcast this store. Some of the big reasons why I (and probably others on this thread) are motivated to not use a Context is because:

1. global stores ensures only a single instance of it can ever be spawned
2. global stores are agnostic to platforms. for example, i can interact with the store from non-React components like arbitrary util functions that exist outside of React
3. global stores are easier to test b/c you can access the store without React test tools like RTL and don't have to setup any render(ui, wrapper) nonsense

probably could list more reasons, but these are the big ones for me. in case others want some solution to using global stores during SSR, this is what i had to do.

define a store.initialize(settings) to get the state to some "initial" state. also define a store.reset() action that updates the store back to its initialState.

export const store = createStore<MyStore>()((set, get, ...props) => {
  const resetState = {
    ...initialState,
    ...createSliceA(set, get, ...props),
    ...createSliceB(set, get, ...props),
    ...createSliceC(set, get, ...props),
  };

  return {
    initialize: (settings) => { // update store to its initial state },
    reset: () => {
      set(resetState);
    },
  }
});

Then, in my React app's entrypoint, render a <InitializeStore> component that accepts SSR props and calls store.initialize() inline (b/c you want it to run server-side). But when running on the server, always call store.reset() before initializing, to ensure any previous state is wiped clean and reset to its initial value.

export function InitializeStore(props) {
  const isServer = typeof window === 'undefined';
  const [initialize, reset] = useStore(s => [s.initialize, s.reset]);
  const isInitializedRef = useRef(false);

  if (isServer || !isInitializedRef.current) {
    if (isServer) {
      reset();
    }
    initialize(props);
    isInitializedRef.current = true;
  }
}

i'm still on the fence about converting our store to a Context store b/c of the reasons mentioned. so hopefully this can help others continue to use global stores, even during SSR.

[dbritto-dev]

@dannobytes just to let you know you can face same issues with redux is not just a Zustand thing

[dannobytes]

💯 yeah, this wasn't trying to single out zustand stores as the culprit for this broader issue. thanks for pointing that out.

the problem is really that any global singleton, basically any mutable object declared at the module-level, will persist on the server but not on the client.

[Pagebakers]

Maybe something could be created with AsyncLocalStorage, where each request has it's own server side store context.

[MehmetKaplan]

Is it possible to completely forbid zustand running on server? (If a user still wants it maybe a zustandDangerouslyDangerDontDoThisPlease type of a polyfill allows it to be run?)

I am by pure luck here and was afraid to read the whole issue. I believe many people will not bother to read the zustand readme's warning.

[Mesqalito]

Didn't read the whole thread, but we use http-context to keep separate instances of zustand stores per each request. We use wrapper function to create out stores which has different implementation for client and server: the server one injects lazyInit into all store accessors (calling as hook, setState, getState, subscribe methods) that checks current httpContext to see if there's a required store instance and if not - creates one. This guarantees that each request has its own store instance on server and prevents data leakage. http-context on server is just a method of having state bound to current thread, as far as I understood.