NextJS and zustand

[alexander-densley]

In the new nextjs guide, it say:
"No global stores - Because the store should not be shared across requests, it should not be defined as a global variable. Instead, the store should be created per request."

Does this mean we can't use the slices pattern? or do we create a general store provider that handles all the slices? Sorry, just having a hard time wrapping my head around zustand best practices and nextjs. Any advice would be awesome. If anyone has a repo or a tutorial of implementing zustand into a nextjs app with multiple stores or multiple slices that would be incredible, thanks!

[alexander-densley]

Ive been trying to implement based off the guide, and Im running into lots of little issues, so a more comprehensive tutorial and an example repo would be incredibly helpful I imagine. Some issues Ive run into are that createContext requires a default value, and useStore is not imported in the guide's code. There are a couple others, but those might be my implementations problem.

[alexander-densley]

Also, after going through jotai documentation, creating a zustand provider to avoid all this set up would be awesome

[dbritto-dev]

@alexander-densley what issues are you facing right now? about slices I don't see why you can't use slice pattern. We are only saying that you should avoid shared store across requests due to that could lead you to some issues even if you don't use Zustand that's something could happen if you are using a global store/variable or module state like Zustand.

[alexander-densley]

@dbritto-dev I guess one of the things Im currently confused with is the implementation of these custom providers. Do we have to make a provider for each slice we create, cause if the case thats quite the headache? and if so where and how should they be wrapped around layouts and components. I would love to see a more comprehensive guide explaining whats going on because it is a lot more hands on and boilerplate than traditional zustand

[tyler-audio]

That would be incredibly helpful and appreciated, I'm sure others would agree.

[alexander-densley]

I would love this demo if it's still on the table

[Vee-ble]

@dbritto-dev Sir, Can I get reference nextjs + slice pattern?
Is it possible to apply the slice pattern when implementing initializing-the-store of document next?

[dbritto-dev]

@Vee-ble sure

[alexander-densley]

any updates on this? no rush, thanks for being so helpful!

[HasanMothaffar]

the store should not be shared across requests, it should not be defined as a global variable.

I'm a bit confused by this statement after reading the Next.js integration guide. Does this only concern server-side (Node.js environment) only or both server and client? I'm using Zustand in my Next.js projects (pages directory) as a global store, but only on the client-side, nothing on the server, and from what I've seen each request has its own store. So I was wondering if I should also migrate to using Zustand with React Context.

P.S Thank you for creating/maintaining this awesome library!

[dbritto-dev]

@HasanMothaffar let me explain you a little bit, first of all you need to keep in mind that:

• there's no state on the server, just an initial state: the first rule that we need to follow is that we should have the same initial state on server and client if there's something that could be different that lead us to some hydrations errors. I would like to say that we are talking about a build time state, so any initial state should be treated as a build time state so we can ensure that we have the same state on both sides (server and client)
• you can't read/write a state from the server: let's say that since there's no state on the server just an initial state, there's no way to go back and read/write to that state
• everything should be created per request: to keep everything isolated we should create the store per request and then sync the data to make that everything works as expected assuming that there's a store that you read from a global store could lead you to some bugs and hydration errors, for instance going to an authenticated page where we can see the authenticated page first and then the login page, etc

[HasanMothaffar]

@dbritto-dev To be honest I didn't really understand your reply. I am familiar with ideas from 2200, 2058, 182. Maybe I didn't explain my question in a clear way, sorry. I'll use an example to remove ambiguity.

Consider a demo Next.js project (using pages directory).

// auth-store.ts
const useAuthStore = create((set) => ({
    user: "Initial",
    setUser: (user: string) => set({ user }),
}));

// pages/first.tsx
const First = () => {
    const [user, setUser] = useAuthStore((s) => [s.user, s.setUser]);
    return (
        <div>
            {user}
            <button onClick={() => setUser("Changed")}>Change User</button>
        </div>
    );
};

// pages/second.tsx
const Second = () => {
    const user = useAuthStore((s) => s.user);
    return <div>{user}</div>;
};

As indicated, no special server-side functions are called (such as getServerSideProps). This is what I meant by client-only in my question above.

Now if a user performs these actions in order:

Action	User Value
1. Visit first page	Initial
2. Click on button in first page	Changed
3. Visit second page from another browser/tab	Initial

It seems like the global store is not shared between requests. This is why I was confused, because the integration docs and all issues/discussions state that the singleton store is shared.

I did another experiment and came to the conclusion that the store is shared between requests only when using server-side functionality (SSR, RSCs).

If I change the above example to this

// pages/first.tsx
const First = () => {
    return <></>
};

export const getServerSideProps = () => {
    useAuthStore.setState({ user: "Changed" })
}

And after visiting the first page in browser 1, the auth store will have user: Changed. Now when visiting second page even from other browsers, a hydration error will occur because on the server, user = Changed, but on the client user = Initial. In other words, the store is shared between requests.

Now my question is: Is this issue only relevant when I set values from the server side using functions like getServerSideProps or using RSCs?

Is it safe for me to use Zustand as a global store when I don't have SSR/RSCs/server-side functionality and store is not initialized with data from server?

Thanks again for your time! I appreciate it.

[dbritto-dev]

@HasanMothaffar sure, let me explain you two scenarios:

On nextjs any component is rendered/initialized twice, one on the backend and one the client.

When is safe but:

• not recommended: when you use a global store, the initial state is the same on both (server and client) and the initial state doesn't depends on something on the server, but keep in mind if something changed and now your initial state depends on something on the server, now you are not safe anymore and you need to use the recommended way
• recommended: when you use a app/page/route store, the initial state is the same on both (server and client) and the initial state doesn't depend on something on the server

As you can see I'm not talking about RSC or SSR but in those cases we are talking about server, that's why in those cases is common to face hydration issues because people forgot to keep in mind the rules.

By the way try this:

// auth-store.ts
const useAuthStore = create((set) => ({
    user: `Initial ${Math.random()}`,
    setUser: (user: string) => set({ user }),
}));

[dbritto-dev]

@HasanMothaffar lmk if that makes sense

[HasanMothaffar]

@dbritto-dev Yes, that makes sense to me. I tried the example and faced a hydration error, and I understand the situation in which context is necessary. Thank you!

[TimurKr]

Hey @alexander-densley, I have been struggling with this as well but got it working after some time. I created a little library that summarizes all of the boilerplate of working with slices, immer and context. It is literally a single file, so feel free to copy the code and paste it into your app, or install it using npm. I think it might be helpful to many Next.jsdevelopers, so I'm doing a shameless plug here😅.

zimmer-context

I also thought about making a pull request to add this to the thir-party-libraries section in the docs, but I am not sure it is with it, as it really is about 100 lines of code, what are your thoughts? Maybe part of this could be implemented directly into zustand, to make it easier to create a context provider, and the useStore hook, as specified here

[dbritto-dev]

@TimurKr keep in mind that nothing should be global talking about nextjs, everything should isolated at app or page/route level

[TimurKr]

Yes, I keep reading this in different discussions and tutorials, but what does that actually mean?

If I create a store, use context provider and access it only in client components, why wouldn't it work? I can additionally initialize it on the server with data, and then when it is re-rendered on client, everything matches and there is no hydration error. At least that's the way I have it set up in my app and seems to be working so far.

But I admit I am not really sure what you mean be local/global state. Especially when it comes to useStore and context, which is the recommended way of working in the app directory in next.js.

[dbritto-dev]

@TimurKr I explained some parts here -> #2326 (reply in thread)

[dbritto-dev]

yeah, the recommended way to use global stores in general not only Zustand is by creating/initializing them using a context at app or page/route level