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

Hydrate state from cookies without server side rendering #22

Closed MonsterDeveloper closed 2 years ago

MonsterDeveloper commented 2 years ago

Hi! I'm trying to implement this library, and it works great, when the page has some SSR methods (like getServerSideProps or others), however, I am missing one important function - it can't hydrate the state from cookies when the page doesn't have SSR.

So I have some state in cookies, and it hydrates perfectly when page has gSSP method. However, when there are no SSR methods on page, next-redux-wrapper doesn't call HYDRATE action and the state is not fetched from cookies.

My question is: can I hydrate the state from cookies on client-side without using gSSP or other server-side rendering methods?

MonsterDeveloper commented 2 years ago

As a quick workaround I've created an empty getStaticProps method, which enables state hydration from cookies and doesn't disable Next.js static optimization:

const emptyGetStaticProps = wrapper.getStaticProps(() => () => ({
  props: {},
}));

// in Page: export const getStaticProps = emptyGetStaticProps
bjoluc commented 2 years ago

Hi @MonsterDeveloper, thanks for opening this issue! Your use case is very valid and should definitely be supported. The relevant section regarding this in next-redux-wrapper is here. Now I'm wondering: Despite the initial client-side render, is there any moment where the state should be read from cookies even though a page doesn't have "SSR methods"? If not, maybe we can find a way to simply dispatch a HYDRATE action in next-redux-cookie-wrapper when the app loads and state cookies are present. This would obviously result in a duplicate HYDRATE action being dispatched on initial page loads of pages that have said methods. Maybe there's some workaround for that, but I'm not sure how it might look like. Wdyt?

MonsterDeveloper commented 2 years ago

I’ve also thought about dispatching hydrate action, but I’m not sure where to take this initial data from.

So I think some modifications can be made: on initial page load, check if page doesn’t have gSSP, gSP or gIP. If it does, continue as normal. Otherwise read state from cookies and dispatch hydrate action.

Also we don’t need to hydrate state from cookies when navigating pages after initial load.

Do you think it’s possible to create such modifications?

bjoluc commented 2 years ago

Also we don’t need to hydrate state from cookies when navigating pages after initial load.

Great, that's what I wanted to hear :smile:

on initial page load, check if page doesn’t have gSSP, gSP or gIP.

That's the problem: We're just a Redux middleware and there's no way for us to simply tell if the current page has these methods – at least none that I know of. I also checked the context argument that next-redux-wrapper provides to the makeStore function: It's always an empty object on the client side. Hence, I think the best chance we have is to always dispatch an initial HYDRATE action when a store is created on the client side. If there's gSSP, gSP or gIP on the first page a client visits, then there would be two HYDRATE actions: One with the up-to-date cookie data, and one with gSSP, gSP or gIP and cookie data. I don't think that's much of a problem though.

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 2.1.2 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

MonsterDeveloper commented 2 years ago

Thank you! I’ll try it soon.