Using persistant Zustand store within Next.js hydrating Zustand before SSR

[christianjuth]

TLDR; I think Zustand, when persisting within a Next.js app should let you hydrate Zustand server side and client side

I had the idea to persist my Zustand store using cookies. This means I can read/write to the cookie client side, and Server Side Rendered (SSR) my Next.js site with Zustand already hydrated, without worrying about a SSR hydration html mismatch.

I created a demo that allows you to select a sort preference for a list. The preference is stored and persisted via Zustand, and the list is SSR with the list already sorted.

• Try the demo on vercel.
• See the code.
  • The readme explains how Zustand is setup

I'm not sure if I'm doing a good job explaining, but I would love to get your thoughts:

• Is this a use case that interests you?
• Is there a better way to do this?
• Anything I can clarify better?

[dbritto-dev]

@christianjuth you can't hydrate on server side only on client side. I encourage you to read our SRR and Hydration guide.

[christianjuth]

@dbritto-dev Next.js should handle this automatically.

Good to know: cookies() is a Dynamic Function whose returned values cannot be known ahead of time. Using it in a layout or page will opt a route into dynamic rendering at request time.
(source)

Durning SSR I'm using import { cookies } from "next/headers" to hydrate Zustand. When Next.js sees this function called in a page/layout, the page automatically becomes dynamic, which means it's re-rendered each request, and has access to that request's cookies.

So I think users/session isolation shouldn't be an issue here?

[dbritto-dev]

@christianjuth dynamic rendering only means that you rendering at request time but that doesn't mean that you are isolating stores between requests

[dbritto-dev]

seems you are trying to share data across requests through nextjs

[dbritto-dev]

you can even have the same recommendations using redux -> https://redux.js.org/usage/nextjs

[christianjuth]

@dbritto-dev oh that's an interesting point.

I could restructure my React app to prevent that by creating the store per request, and passing it down via React Context.

I'm not married to my specific solution, but I still think having a way to hydrate the store for SSR should be possible. And I think with a little more modification, I could make my solution work reliably?

Am I on the right track at least? Is this a bad idea? I could make this a library that hooks into Zustand, if you think this could be useful for others?