SSR store missing cookie data in Next 13

[wbobeirne]

Hey there, I've copied the example code identically but using next@^13, and I'm getting an hydration mismatch. It looks like my store is being initialized empty despite the cookies existing:

4. useWrappedStore created new store with { initialState: undefined, initialStateFromGSPorGSSR: undefined

Were there any breaking changes in 13?

[bjoluc]

Hi @wbobeirne,

I just updated the demo to next-redux-wrapper 8 and next 13 but was unable to reproduce the issue – unless temporarily when I forgot to remove wrapper.withRedux after adding wrapper.useWrappedStore in _app.ts 😄 Assuming that is not your problem, would you mind creating a minimal repro based on the demo project so I can take a look?

[abrouaux]

Hey @bjoluc, actually I'm also seeing a react hydration error on my end in the demo of this project.

To repro, just increase the counter on one of the getStaticProps page, then reload the page.
In this case, I don't see the hydration step as the first step done on the SSR store, therefore the HTML is generated with the default values, which React is picking on client-side as it's rendering with the cookie value.

This doesn't happen with the getServerSideProps pages.

[bjoluc]

Hi @abrouaux,

In this case, I don't see the hydration step as the first step done on the SSR store, therefore the HTML is generated with the default values, which React is picking on client-side as it's rendering with the cookie value.

The behavior you describe is intended, I'm afraid: getStaticProps is run at build (/regenerate) time, not per request. Hence, it doesn't have a specific client's cookies available and can't hydrate the server-side store with cookie values. If you need this, make sure you are using getServerSideProps.

[abrouaux]

@bjoluc aw crap, you're totally right - this fact completely slipped my mind.

An advice: it would help others to mention this in the various use cases of your example.
In hindsight, it's obvious that the getStaticProps pages are pre-rendered & then served "as they were".
But then the only interesting use-case for redux/cookie interactions is about SSR - via getServerSideProps.

Cheers!

[bjoluc]

An advice: it would help others to mention this in the various use cases of your example.

That's a good point! Maybe we should add a little notice on the static example pages, explaining what happens. WDYT?

[abrouaux]

Actually I'm not even sure you should provide "getStaticProps" cases in your example - the only value of storing redux data in a cookie is to pre-render stuff based on client data.

[bjoluc]

the only value of storing redux data in a cookie is to pre-render stuff based on client data.

@abrouaux That's right. Nevertheless, it's important that state from getStaticProps doesn't affect client/cookie state for the configured subtrees, while still being applied to other subtrees. Static pages showcase just that...