zustand/middleware persist option to set initializeWithValue

[knajjars]

The problem

With frameworks that do hydration like Next.js, we have the following flow:

1. The server renders /my-page where there is no persisted store (localStorage), therefore the default values are used and renders the page with them.
2. Then the client renders the HTML, but since the persisted store is sync, the values are available on the first render, which could be different from the default values, the ones that the server used to render (THIS IS THE ISSUE).
3. We get hydration error

Proposal

It would be beneficial to include an option to set if the persisted store should be initiated with values (sync) or not (async).

create<StoreState>()(
  persist(
    (...a) => ({
      ...myStore(...a)
    }),
    {
      name: 'MY-STORE',
      initializeWithValue: false // default to true?
    }
  )
)

This should make the storage async by default, meaning on the first render the persisted values will be undefined, matching what was rendered on the server and therefore, potentially avoiding the Rehydration error. Thoughts?

[dai-shi]

This is what I have been wondering and I decided to change "delayInit=true" by default in the next Jotai version's atomWithStorage.

So, can you confirm if zustand v4.2.0 before #1518 actually works as you expect?
If we need to support two conflicting use cases, adding a new option should be the way to go.

[knajjars]

v4.2.0 does not seem to work as expected either

[dai-shi]

Oh, really. Then, I'm not sure if I understand the implementation correctly.

Would anyone like to try implementing it?
A few notes on the implementation:

• Only change newImpl and leave oldImpl unchanged.
• I think the option is named delayHydrate and defaults to false (suggestion welcome)

[dai-shi]

Follow-up comment: #1537 (comment)

[kecoliva]

I agree with this - so far the only solution to this is preventing the page to render if it's not mounted yet. It feels hacky to create a custom hook to check if the page is mounted before rendering to prevent hydration errors.

[dai-shi]

I agree it feels hacky.
Call for contributors: #1537 (reply in thread)

[dai-shi]

Follow-up comment: #1537 (comment)

[dai-shi]

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

[TkDodo]

I'd love to look into this. @knajjars can you maybe show a codesandbox reproduction of the current issue ?

[dai-shi]

Moved to #1174 (comment), as it's not only for persist middleware.

[charkour]

Hi @dai-shi, here is a simple reproduction. I'll add this to the main thread.