search

bjoluc / next-redux-cookie-wrapper

Sync a subset of your Redux state with cookies in Next.js :cookie: :sparkles:
MIT License
114 stars 4 forks source link

SSR store missing cookie data in Next 13 #44

Open wbobeirne opened 2 years ago

wbobeirne commented 2 years ago

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 commented 2 years ago

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 :smile: 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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...