support default value using getServerState

[himself65]

I see there's a field called getServerState, but I don't see any usage of this API

zustand/src/react.ts

Line 38 in 49dcec0

api.getServerState || api.getState,

If we support like this, that will help SSR on next.js

import { ssr } 'zustand/middleware'
const defaultValue = { ... }
create(
  ssr(set => ({ ... }), () => {...defaultValue})
)

Upstream: #1145

[dai-shi]

Thanks for asking!
We have getServerState, but don't know how to use it yet.
So thanks for your help. Once we figure it out, let's write a doc.

getServerState has nothing to do with vanilla store, thus only defined in react.ts.

I'm hoping something like this would work:

const defaultValue = { ... }
const useFooStore = create((set => ({ ... }))
useFooStore.getSererState = () => defaultValue

How's it?

[dai-shi]

But, but maybe it's not that bad idea.

[dai-shi]

tbh, I'm not so experienced with ssr, and not even sure if this is a good approach. there would be many issue reporting on it. so, it's more comfortable for me to start it as a 3rd-party library. and, we will see.

[himself65]

but in your example, you call create first, and it already passes getServerSnapshot = api.getState into useSyncExternalStore, I think that might won't work

[dai-shi]

create doesn't invoke useSyncExternalStore. Would you please give it a try? I need to re-consider if it doesn't work...

[himself65]

create doesn't invoke useSyncExternalStore. Would you please give it a try? I need to re-consider if it doesn't work...

Oh, my bad. your idea works. Let me try a PR for it

[laclance]

any updates?

[arashi-dev]

no updates? :)

I saw this document: https://github.com/pmndrs/zustand/blob/bf9d0922fe9292c2399b9594eafe9304016b52d9/docs/guides/initialize-state-with-props.md

and thought maybe I can make it easier:
https://gist.github.com/arashi-dev/a8d01d206f4c315faef5c888d33f03df

I'm not sure if I did it right. it would be great if any of you can check it and give some idea :)

[arashi-dev]

@dai-shi
thanks for the comment. I will keep working on it.

any news about the getServerState? I think a solution by the maintainer (you) is far better than someone like me creating a third-party library

[arashi-dev]

also, at first, before reading the context approach, I had a simple project and this is how I solved the issue:

const makeStore = () => create({...})

_App.tsx

const isMountedRef = useRef(false)
const [myStore] = useState(makeStore)

if(!isMountedRef.current) {
    myStore.getState().hydrate.handler(props.zustand.myStore)  
    isMountedRef.current = true
}

however, I created some other functionality to make it work for multiple stores automatically (something like the gist I created).
and it was working well

[arashi-dev]

the idea of hydrate.handler() is from next-redux-wrapper which we had to add a HYDRATE action and handle merging server-side and client-side states

[arashi-dev]

happy new year btw :)

[dai-shi]

any news about the getServerState?

I think it's probably correct from the implementation perspective.
Unfortunately, I'm not super familiar with SSR best practice.
We need someone to help on this.

[tushar1998]

@dai-shi @himself65
The feature can be something like

• Default value should be able to set on the server and then on client we wont need loading state
  OR
• The create functio should have the ability to take default value

const useCountStore = create(getDefaultValue, (set)=>{
   // ctx is placeholder for any data you want from or the first parameter can a object handled by user
   const defaultValue = getDefaultValue(ctx); // { count: 10 }
   
    return {
        ...defaultValue,
        resetMethod: () => set({count: 0})
    }
})

[tushar1998]

@dai-shi
Currently I am using zustand + context provider but it will be amazing if its available directly in zustand

Does jotai solves my issue 👀?

[dai-shi]

If you need to run components on server (aka SSR), context would be required anyway to isolate state between sessions.

Jotai might work better with context, but it's still client states. So, essentially there is the same difficulty in either case.

[tushar1998]

They have useHydratedState hook

So I made a component out of it like Hydrate in react-query

export function HydrateAtoms({
  children,
  atoms,
}: PropsWithChildren<HydrateAtomsProps>) {
  useHydrateAtoms([...atoms])
  return children
}

[dai-shi]

useHydrateAtoms is technically same as running useCountStore.setState(defaultValue) just once.

const initialized = useRef(false);
if (!initialized.current) {
  initialize.current = true;
  useCountStore.setState(defaultValue);
}

[tushar1998]

Yeah, I realized that later after comparing both.
But on ground 0 if the states wont get updated on client side I wont either need atom or zustand, react context is enough for just sharing the server state onto its children client components

[dai-shi]

#1537 (comment)

I think we should move the discussion here.

https://twitter.com/dai_shi/status/1716304792786747646 We had a discussion in Twitter/X, which changed my mind.

I don't think we should add a new option delayHydration which is suboptimal, and it somewhat conflicts with skipHydration option.

Instead, we should explore the use of .getServerState() to avoid the React hydration error. My understanding is that we don't need to modify Zustand code. It's how we use it. So, it will be for docs, once we figure it out.

Would anyone be able to help? I think we need a minimal repro first. cc @TkDodo @pawelblaszczyk5 @dbritto-dev

If @knajjars can't provide a reproduction, can anyone follow? cc @charkour

[dai-shi]

Thanks for the investigation.
What I would like to explore as a new solution is the use of getServerState, which I hope to avoid skipHydration. I'm not yet sure if it's possible, but what do you think if it would be possible?

[TkDodo]

Looked into this a bit today. I can see that zustand has api.getServerState, and getServerSnapshot of useSyncExternalStore also reads from it, but it's not actually set somewhere, so we just fall back to getState:

https://github.com/TkDodo/zustand/blob/9857a676a94c81ec561f99a13d46d6f6f3376f84/src/react.ts#L68

now getState will contain the state hydrated from localStorage via the persist middleware, so I think what we would need to do is capture the initialState and add getServerState to the api returned from createStore.

I have a PR up here:

• feat: getInitialState #2277

(just to get a codesandbox preview up and running so I can validate against the minimal example). If that works, I think we would still need a test that combines SSR with persist ?

[dai-shi]

but it's not actually set somewhere,

Yes, you must define it on your end (at least in the current design).

via the persist middleware

What I avoided is to add getServerState concept in vanilla, because it's React-only things. And persist is in vanilla. This complicates things though.

[TkDodo]

This complicates things though.

yes it does because as far as I can see, we actually don't have access to the initialState inside createStore when combined with persist. One way to fix this would be to have persist alter the api to add getServerState, which wouldn't be unreasonable imo. It's a client side feature that alters what getState returns, so for it to work with server rendering, it must somehow expose the original state. Right now, it "swallows" it.

[dai-shi]

Just saw https://github.com/pmndrs/zustand/pull/2277/files#r1438180754. If I understand it correctly that that approach works, it's pretty simple.

[charkour]

@himself65, thanks for reporting this! I was also confused that getServerState is defined but not implemented and has no documentation. We'll see about make a change to avoid confusion.

@dai-shi, I propose we deprecate getServerState and remove it in v5 because it does not seem to be necessary. What do you think?

[dbritto-dev]

@charkour I'm down with you we shall deprecate getServerState

[himself65]

thanks for reporting this!

I reported this 1 year ago🤯

[dai-shi]

Perhaps we should update these docs with more Next.js best practices.

#2259 (comment)