NextJS and zustand #2326

alexander-densley · 2024-02-12T17:40:47Z

alexander-densley
Feb 12, 2024

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!

Answered by dbritto-dev

Feb 20, 2024

@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 …

View full answer

alexander-densley · 2024-02-12T18:01:42Z

alexander-densley
Feb 12, 2024
Author

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.

2 replies

YenHub Jul 10, 2024

Hey @alexander-densley

Working with Slices in NextJS is not too dissimilar from the normal Store setup.

There are just a couple of tweaks you need to make to break your store down into slices and consume them from a Provider.

The example below largely mimics the suggested approach in the Zustand Docs, albeit; using Slices.

Here is some example boiler-plate to help get you going:

Tree Structure (NextJS 14)

src/
├── app/
│   ├── layout.tsx
│   └── page.tsx
└── lib/
    ├── components/
    │   └── StoreTest/
    │       └── index.tsx
    ├── providers/
    │   └── app-store-provider.tsx
    └── store/
        ├── slices/
        │   └── appSlice.ts
        ├── defaultState.ts
        └── index.ts

Files

/src/app/layout.tsx

import type { Metadata } from 'next';
import { Inter } from 'next/font/google';

import { AppStoreProvider } from '@/lib/providers/app-store-provider';

const inter = Inter({ subsets: ['latin'] });

export const metadata: Metadata = {
  title: 'Zustand Store Slices Demo',
  description: 'A demonstration of using Slices in NextJS 14 ',
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={inter.className}>
        <AppStoreProvider>{children}</AppStoreProvider>
      </body>
    </html>
  );
}

/src/app/page.tsx

import { StoreTest } from '@/lib/components/StoreTest';

export default function Home() {
  return (
    <main>
      <StoreTest />
    </main>
  );
}

/src/lib/components/StoreTest/index.tsx

'use client';

import { useStore } from '@/lib/providers/app-store-provider';

export const StoreTest: React.FC = () => {
  const { isLoading, setIsLoading } = useStore(state => ({
    isLoading: state.isLoading,
    setIsLoading: state.setIsLoading,
  }));

  return (
    <form action="javascript:void(0);">
      <label htmlFor="storeval">Current Value:</label>
      <br />
      <input
        disabled
        id="storeval"
        name="storeval"
        type="text"
        value={String(isLoading)}
      />
      <br />
      <input
        type="button"
        value="Set Is Loading"
        onClick={() => setIsLoading(!isLoading)}
      />
    </form>
  );
};

/src/lib/providers/app-store-provider.tsx

'use client';

import { createContext, type ReactNode, useContext, useRef } from 'react';
import { type StoreApi, useStore as useZustandStore } from 'zustand';

import { createAppStore, initStore, Store } from '@/lib/store';

export const AppStoreContext = createContext<StoreApi<Store> | null>(null);

export interface AppStoreProviderProps {
  children: ReactNode;
}

export const AppStoreProvider = ({ children }: AppStoreProviderProps) => {
  const storeRef = useRef<StoreApi<Store>>();
  if (!storeRef.current) storeRef.current = createAppStore(initStore());

  return (
    <AppStoreContext.Provider value={storeRef.current}>
      {children}
    </AppStoreContext.Provider>
  );
};

export const useStore = <T,>(selector: (store: Store) => T): T => {
  const appStoreContext = useContext(AppStoreContext);

  if (!appStoreContext) {
    throw new Error('useStore must be use within AppStoreProvider');
  }

  return useZustandStore(appStoreContext, selector);
};

/src/lib/store/slices/appSlice.ts

import { StateCreator } from 'zustand';

import { Store } from '@/lib/store';

export interface AppState {
  isLoading: boolean;
}

export type AppActions = {
  setIsLoading(isLoading: AppState['isLoading']): void;
  resetAppState(): void;
};

export type AppSlice = AppState & AppActions;

export const initialAppState: AppState = {
  isLoading: false,
};

export const createAppSlice: StateCreator<Store, [], [], AppSlice> = set => ({
  ...initialAppState,
  setIsLoading: isLoading => set({ isLoading }),
  resetAppState: () => set(initialAppState),
});

/src/lib/store/defaultState.ts

import { AppState, initialAppState } from './slices/appSlice';

export type StoreState = AppState;

export const defaultState: AppState = {
  ...initialAppState,
};

/src/lib/store/index.ts

import { createStore } from 'zustand/vanilla';

import { defaultState } from './defaultState';
import { AppSlice, AppState, createAppSlice } from './slices/appSlice';

export type Store = AppSlice;

export const initStore = (): AppState => {
  return defaultState;
};

export const createAppStore = (initState: AppState = defaultState) => {
  return createStore<Store>()((set, get, store) => ({
    ...initState,
    ...createAppSlice(set, get, store),
  }));
};

HamishClulee Nov 30, 2024

@YenHub You are the real MVP for this... thanks a million!

alexander-densley · 2024-02-12T18:08:52Z

alexander-densley
Feb 12, 2024
Author

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

0 replies

dbritto-dev · 2024-02-12T18:42:39Z

dbritto-dev
Feb 12, 2024
Maintainer

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

0 replies

alexander-densley · 2024-02-12T20:27:40Z

alexander-densley
Feb 12, 2024
Author

@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

9 replies

tyler-audio Mar 15, 2024

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

alexander-densley Mar 19, 2024
Author

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

Vee-ble Apr 25, 2024

@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 Apr 25, 2024
Maintainer

@Vee-ble sure

alexander-densley May 13, 2024
Author

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

HasanMothaffar · 2024-02-19T04:40:53Z

HasanMothaffar
Feb 19, 2024

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!

11 replies

dbritto-dev Feb 19, 2024
Maintainer

@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 Feb 20, 2024

@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 Feb 20, 2024
Maintainer

@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 }),
}));

Answer selected by dbritto-dev

dbritto-dev Feb 20, 2024
Maintainer

@HasanMothaffar lmk if that makes sense

HasanMothaffar Feb 24, 2024

@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!

danbeo95 Jun 26, 2024

hi @dbritto-dev As you said: "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". Is it correct with Math.random() case?

dbritto-dev Jun 26, 2024
Maintainer

@danbeo95 no, is not. We want to make sure that server and client first render are the same, and with Math.random we can't do that.

TimurKr · 2024-02-19T16:32:02Z

TimurKr
Feb 19, 2024

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

4 replies

dbritto-dev Feb 19, 2024
Maintainer

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

TimurKr Feb 19, 2024

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 Feb 19, 2024
Maintainer

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

dbritto-dev Feb 19, 2024
Maintainer

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

dalalRohit · 2024-06-13T07:43:36Z

dalalRohit
Jun 13, 2024

i am also facing the same issues since last few days. Can't get the head around on how to use multiple store slices along with context-providers & RSC.

Any example or instructions help would be highly appreciated. Thank you.

3 replies

dbritto-dev Jun 13, 2024
Maintainer

@dalalRohit what's the difficult part of implementing slices pattern? should be the same without context, the only difference is that now we are using createStore and Context API but both create and createStore support slices pattern

dalalRohit Jun 13, 2024

thank you @dbritto-dev for quick reply.

as per the next.js setup doc, the layout.tsx is using < CounterStoreProvider /> Provider from counter-store slice. What if we have multiple such slices? Does it mean we have to add multiple providers; one for each slice? Isn't that tedious to create multiple such providers?

Do I do Something like this?

<CounterStoreProvider>
   <FishSliceProvider>
       //keep nesting multiple providers here
       {children}
   </FishSliceProvider>
</CounterStoreProvider>

Again, you guys are awesome. Thanks for such an amazing lib, cheers! 🍺

dbritto-dev Jun 13, 2024
Maintainer

@dalalRohit when we talked about slices pattern we are talking about just one store. BTW, counter store is not a slice its a single store. For multiple stores, you need multiple providers.

donprasetiyo · 2024-06-14T07:37:56Z

donprasetiyo
Jun 14, 2024

Can anyone explain how the tsconfig from the doc (https://docs.pmnd.rs/zustand/guides/nextjs#creating-a-store-per-request) makes the store created per request? Would it be fine if I don't use the same tsconfig?

3 replies

dbritto-dev Jun 14, 2024
Maintainer

@donprasetiyo I wonder why you think that creates a store per request, but no. What creates a store per request is the usage of Context API.

donprasetiyo Jun 18, 2024

Thanks. It was the doc's heading ("Creating a store per request") that made me think that.

dbritto-dev Jun 26, 2024
Maintainer

@danbeo95 may, you didn't notice that the main title is Creating a store per request and then the other titles are part of that, like h1 and then h2s.

NextJS and zustand #2326

Replies: 8 comments · 32 replies

alexander-densley Feb 12, 2024 Author

Tree Structure (NextJS 14)

Files

alexander-densley Feb 12, 2024 Author

dbritto-dev Feb 12, 2024 Maintainer

alexander-densley Feb 12, 2024 Author

alexander-densley Mar 19, 2024 Author

dbritto-dev Apr 25, 2024 Maintainer

alexander-densley May 13, 2024 Author

dbritto-dev Feb 19, 2024 Maintainer

dbritto-dev Feb 20, 2024 Maintainer

dbritto-dev Feb 20, 2024 Maintainer

dbritto-dev Jun 26, 2024 Maintainer

dbritto-dev Feb 19, 2024 Maintainer

dbritto-dev Feb 19, 2024 Maintainer

dbritto-dev Feb 19, 2024 Maintainer

dbritto-dev Jun 13, 2024 Maintainer

dbritto-dev Jun 13, 2024 Maintainer

dbritto-dev Jun 14, 2024 Maintainer

dbritto-dev Jun 26, 2024 Maintainer

Replies: 8 comments 32 replies

alexander-densley
Feb 12, 2024
Author

alexander-densley
Feb 12, 2024
Author

dbritto-dev
Feb 12, 2024
Maintainer

alexander-densley
Feb 12, 2024
Author

alexander-densley Mar 19, 2024
Author

dbritto-dev Apr 25, 2024
Maintainer

alexander-densley May 13, 2024
Author

dbritto-dev Feb 19, 2024
Maintainer

dbritto-dev Feb 20, 2024
Maintainer

dbritto-dev Feb 20, 2024
Maintainer

dbritto-dev Jun 26, 2024
Maintainer

dbritto-dev Feb 19, 2024
Maintainer

dbritto-dev Feb 19, 2024
Maintainer

dbritto-dev Feb 19, 2024
Maintainer

dbritto-dev Jun 13, 2024
Maintainer

dbritto-dev Jun 13, 2024
Maintainer

dbritto-dev Jun 14, 2024
Maintainer

dbritto-dev Jun 26, 2024
Maintainer