How to use with next.js with splitting your app state into pages

[meglio]

Next.js example with-zustand says:

Usually splitting your app state into pages feels natural but sometimes you'll want to have global state for your app.

Could you please provide a canonical example of using zustand in Next.js with that exact approach - i.e. a fresh client-side only store per page?

-- Many thanks,
Anton

[meglio]

... to add to my question and make it more clear, the with-zustand Next.js example README also says:

On the server side every request initializes a new store, because otherwise different user data can be mixed up. On the client side the same store is used, even between page changes.

So what I'm looking for is the exact opposite - i.e. I don't want the same store to be used, "even between page changes".

So, I need the following workflow:

1. Next.js either
   a) renders the page server-side and then hydrates it client-side (when opening the website in a new tab), OR
   b) only fetches data and renders client-side (when navigating between pages).

2. My page receives properties, which I want to use as the initial values for my store.

3. I'd like the store to always "start from scratch" no matter what, i.e. if I navigate between pages, or reload the website entirely.

Is this something that'd be easy to achieve with zustand?

[dai-shi]

@Munawwar or anyone?

[Munawwar]

Full example at https://codesandbox.io/s/nextjs-with-zustand-354-forked-bryjr?file=/lib/store.js

I've forgotten to update the next.js repo with the last change in interface, but the code is supposed to also be at https://github.com/vercel/next.js/tree/canary/examples/with-zustand

[Munawwar]

Oh wait, you don't want to use the same store between pages on client side? I haven't tried it yet, but maybe you can create new context inside App, but you will need to keep a global reference somewhere so that consumers can import the correct useStore() hook?

[meglio]

@Munawwar I can't understand what you mean. Could you try in different words?

[Munawwar]

@meglio Ok I tried my initial idea. It didn't work. The only way with our current context approach is to reset all the states inside the same store. https://codesandbox.io/s/nextjs-with-zustand-test-5nk81?file=/lib/store.js:1566-1807

[zane-commeatio]

I don't know if its the exact thing you are looking for, but i use several stores in my pages based on need.
I just name differently my stores in the function definition and i'm able to import the store i want, where its needed, without fancy stuff.

[meglio]

I don't know if its the exact thing you are looking for

@goupilAnthony it's not what I was asking about, so you should have misunderstood.

[billymcintosh]

3. I'd like the store to always "start from scratch" no matter what, i.e. if I navigate between pages, or reload the website entirely.

This sounds like you don't need any benefits from a store and therefore don't need Zustand. If you want to start from scratch each request, create an object in getServerSideProps or getInitialProps.

[meglio]

This sounds like you don't need any benefits from a store and therefore don't need Zustand.

Wrong. I am using the benefits from a store and I do need Zustand. Otherwise I'd be using Context or something like that.

Please let's stick to solving the problem I described, I'm not asking whether using Zustand is practical in my case or not. Many thanks.

[billymcintosh]

This sounds like you don't need any benefits from a store and therefore don't need Zustand.

Wrong. I am using the benefits from a store and I do need Zustand. Otherwise I'd be using Context or something like that.

Please let's stick to solving the problem I described, I'm not asking whether using Zustand is practical in my case or not. Many thanks.

Nice attitude towards people who are trying to help you. You'll go far.

Rather than simply asking for people to do your R&D, perhaps show us what you've attempted then elaborate on what exactly it is you want. Perhaps someone with more tolerance than me will help you.

[Munawwar]

I do see a global state manager being useful even when app is mostly client-side. There are even some using next.js like an SPA with zustand (famous one is Tanner Linsley, creator of react-query). So.. let's continue with the initial question.

The reason why the flow gets difficult is because on client-side with next.js, page navigation does not clear _app's local states, rather tries to "hydrate" it's states (regardless of whether the page you are navigating to was built for SSR/SSG or not). As mentioned, with the current API, the only way I could achieve what OP is looking for, is by replacing the contents of existing store on page navigation - https://codesandbox.io/s/nextjs-with-zustand-test-5nk81?file=/lib/store.js:1566-1807
I suggest checking out that code and providing feedback whether it works out or not.

If it doesn't work out, and unless someone (with more experience with next) can come up with a better solution that fits with the current API, a better solution would be to change the API to be more like (forgive the shameless plug), another state manager I've written react-global-states, where hooks are not passed through the provider. But that is a breaking change, and we would have to evaluate carefully.

[meglio]

elaborate on what exactly it is you want

@billymcintosh , it is in the very beginning of this thread, in my first message. Here is what I need:

Could you please provide a canonical example of using zustand in Next.js with that exact approach - i.e. a fresh client-side only store per page?

... and then in the next message:

I don't want the same store to be used, "even between page changes".

So I'm not asking anyone to do my R&D. I know exactly what I need. I don't know what is the right (canonical) way to do it with Zustand.

---

P.S. And this does not sound like any help anyway: "This sounds like you don't need any benefits from a store and therefore don't need Zustand."

[billymcintosh]

You are asking for functionality that doesn't exist.

In fact: -

So what I'm looking for is the exact opposite

... of what Zustand & Next.js do.

We all love a coding challenge but forcing software to do the opposite of what it's intended is a code smell and most likely a hacky solution.

Use a POJO, fork Munawwar's code or post what you've got up to so the community can help with this unique edge case.

[meglio]

How is it an edge case?
I need a global store that is fresh in each page.
Is not a "global state" what Zustand does?

---

I do have a working solution, and its logic is similar to what @Munawwar does. I just don't like the approach - it sounds like a workaround rather than a canonical way to have a global state per page. Hence asking.

[Munawwar]

It is a workaround, no doubt (and it doesn't look clean).
I am not sure if more people would use next.js this way. At the same time, the general philosophy has been to not be too opinionated. So, we might have to rethink the API. @dai-shi I'll let you decide.

[dai-shi]

I'm not 100% following, but from:

i.e. a fresh client-side only store per page?

i.e. I don't want the same store to be used, "even between page changes".

What I can say is:

• zustand is primarily for module state (a.k.a. a singleton in memory) and tuned for it.
• it's unopinionated on how to use it and expect the community to be creative. (which also means the library doesn't want to take the responsibility.)
• zustand/context is an unavoidable/unhappy solution because the zustand api design is not very suited for context usage (for ex. per-page store).
• @Munawwar came up with one practice based on zustand/context for nextjs.
• I don't think we need to change zustand/context. It's very basic. It's not nextjs specific.
• Unfortunately I personally am not very familiar with nextjs, and I don't have any proposal at the moment.
• @meglio 's question seems valid. It's just that nobody has a good solution yet. Or maybe impossible in an acceptable way.

[G3root]

@Munawwar can you provide me your example in typescript that could be helpful

[meglio]

@dai-shi so, I'm not suggesting to make Zustand more opinionated. I'm just saying we could try improve the API as to make the problem described above easily solvable.

I still think the problem I described is not only a legit one, but also not specific to Next.js - same problem exists with any single-page applications, where the state is to be shared between components on a page, but not between pages. There should be a way to achieve it without ugly workarounds. It should not affect how the existing features work.

I love the library and I'm using it. It just turned out that for the category of problems that I described above, it is very verbose to achieve simple logic described as "state state between components but not between pages".

[dai-shi]

Now, I'm afraid if I understand the problem or not.
If it's not specific to nextjs, would you create a minimal example with codesandbox (CRA)?
I think we can come up with a practice with key and/or zustand/context, which wouldn't be so ugly, but it depends on how people feel.

[jp185357]

This issue sounds very similar to a question I have on using Zustand with Next. We're trying to use a series of Zustand for local state, one of which containing our current user's data from our DB. Authenticating via MSAL & then fetching DB data and storing this in Zustand.

We're running into the issue where when getting the user's data from the store in useEffect is causing flash re-rendering. I want to be able to fetch the user's data from the Zustand store in getInitialProps but am unable to hook into the Zustand store here obviously because getInitialProps is not React function or hook.

Are there any ways of doing this in getInitialProps without hooking into the Store?

[dai-shi]

I'm not sure how the store is initialized, but useAppStore.getState().user is the way to read the store state outside React render function.

[dthomason]

@dai-shi is correct, it doesn't have to be a hook. By doing useStore.getState() you then have access to any objects or actions. This is how it works with vanilla js.
So for Mr Abrasive, I think there's a misunderstanding, we all want to help, we just don't quite fully know what you're asking. Are you saying you have a single page app with three tab views? If that's the case, just create three separate stores and call them throughout the tree accordingly. Why not experiment and come back with the answer? That would be cool

[schmuecker]

Maybe I can help with @meglio's question.

If I understand correctly, the requirements are the following:

• Have a separate client-side zustand store per page which the page's components can access
• Reset the stores on navigation

I don't have a lot of experience with Next.js, so I will describe the solution with a SPA.

There are two solutions:

1. Create a global store per page and only access it on the page and its children.
2. Create a store per page and use Providers to to force a separation between the pages' stores.

Solution 1: Global stores

Example for page one:

/* stores/pageOneStore.js */

import create from 'zustand'

export default useStore = create(set => ({
  propertyOne: undefined,
  setPropertyOne: (propertyOne) => set({ propertyOne }),
  reset: () => set({ propertyOne: undefined }, true)
  // other properties and actions...
}))


/* pages/PageOne/components/PageOneChild.jsx */

import useStore from '../../../stores/pageOneStore'

function PageOneChild () {
  // Use the store in child components
  const propertyOne = useStore(state => state.propertyOne)

  return (<div>{propertyOne}</div>)
}


/* pages/PageOne/index.jsx */

import useStore from '../../stores/pageOneStore'

function PageOne () {
  // When this page is loaded, write your data into the store.
  // This can be done via e.g. a simple useEffect
  const setPropertyOne = useStore(state => setPropertyOne)

  useEffect(() => {
    const data = loadData()
    setPropertyOne(data.propertyOne)
  }, [])

  // Reset the store on unmount (e.g. when the user navigates)
  const reset = useStore(state => reset)

  useEffect(() => {
    return () => reset()
  }, [])

  return (<div><PageOneChild /></div>)
}

Use the same approach for as many other pages as you want.

Solution 2: Stores with Providers

If you want prohibit pages and their children to access the stores of the other pages, you can use Providers.
Use zustand/context to export a Provider for each store and wrap the associated page in the Provider. This way, only the page and its children has access to the store for that page.

Here are code examples for using zustand with Providers: https://github.com/pmndrs/zustand#react-context

I hope I could help with your problem.

[meglio]

Hi @schmuecker , please note that it's not just per page, it's per page per user (each user will have its own data in each store per page). Should your solution still work in this scenario?

[schmuecker]

@meglio sure, if you make an authenticated request, the user receives their specific data.
This is how it should work in theory, of course I don't know your backend stack.

[dsacramone]

This issue sounds very similar to a question I have on using Zustand with Next. We're trying to use a series of Zustand for local state, one of which containing our current user's data from our DB. Authenticating via MSAL & then fetching DB data and storing this in Zustand.

We're running into the issue where when getting the user's data from the store in useEffect is causing flash re-rendering. I want to be able to fetch the user's data from the Zustand store in getInitialProps but am unable to hook into the Zustand store here obviously because getInitialProps is not React function or hook.

Are there any ways of doing this in getInitialProps without hooking into the Store?

@jp185357 Did you find a solution?

[markomitranic]

Wow just wow. I understand the community is trying hard to help, but also it is so funny to se how much eveyone is struggling to understand the very basic web dev concepts, including OP.

What he is asking for is a state reset on page navigation. In next, its called a page, in react spas a tab. Whatever you call it it is “reset on navigation”. It is not the same as browser navigation, which resets the window, and thus creates a new zustand automatically.

• Imagine a product page (PDP). It needs useMyStuff() zustand because of prop drilling+animation reasons. Has a value quantity in it.
• Zustand store is global, belongs to window.
• NextJS “page navigation” isn’t an actual browser page change, its just a SPA that pretends its a new page.
• When you then navigate to another PDP, it will need zustand with the same name, and will gain access to the global useMyStuff().
• Since its a singleton, the quantity will remain the same as on previous page.

OP doesn’t want that. They want the zustand state to be reset when a navigation event occurs.

Afaik there is no easy solution for this - a spa navigation is a fake navigation and needs a fake solution - other than making a useeffect that listens to any navigation in the app and resets the state explicitly by calling useMyStuff()’s reset method. This has been pointed out by the community in this thread.

What OP said (even tho their wording is a bit aggressive, possibly due to an avalanche of well meaning - but ultimately empty answers) is that it could be super useful if Zustand was expanded so that a store’s fate can (optionally) be tied to a component instead of a window. You’d create a store on the component (perhaps context), in the same way as you do with useMemo in a context. All the children get some nice zustand benefits without being global. Once the navigation happens and context unmounts and remounts, a new fresh zustand store will be created.

All the current patterns (that I’ve seen) that employ a context only store the global reference to zustand, not the actual value, he wants an option to do that - to attach zustand to a variable instead of window.

It is a very good idea, and would expand the usage of zustand onto new avenues. I don’t think its currently doable, we can’t store zustand into a variable, we can only store a reference toward the global object. Zustand’s value isn’ that its global, its main value is the ease of use and performance of selective subscribers. The OP would like to keep those benefits while losing the “globality”.

[Munawwar]

Please don't assume that people here didn't get what the OP wanted and why. It's just that back then, there wasn't a solution short of using useEffects or using vanilla store (which probably wasn't easy).

Anyway this discussion is moot, as OP probably moved on, and zustand changed and next.js has changed as well. The newer recommended way of using context is using vanilla store directly in a context and the hooks are separated from the vanilla store.

https://github.com/pmndrs/zustand?tab=readme-ov-file#react-context

Please create a new issue if that doesn't help.

[markomitranic]

Thanks for sharing the link @Munawwar it is super nice to have it here in this thread, for future readers - of which there are many, at least as many as blogposts that try to teach them how to do this specific thing, meaning this is still an issue, even if it has been solved, simply because it isn't communicated well.

As for assumptions - I made none, everything one needs is eyes to read the messages above. Guy asked a question, and in 3 years got no real answers, just 50 empty messages about how he is using it wrong. Even once there was an officially documented solution - he still didn't get the answer, well, now, thanks to you, he did :)

As for the docs - I was so happy when I first saw this addition, but it turned out to be incomplete. It is also never documented on the Documentation website. The code is incorrect and you need some brain power to get it to work. I'll make a PR with an update. Hopefully that will at least get some eyes on it. Opened #2632 to discuss the wording with the community.