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 ... />}

[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.