Any plans on updating this library to newest wrapper version?

[MaciejWiatr]

Hello, i really love this library however it's becoming more and more outdated. Do you plan to port it to the newest wrapper version?

[bjoluc]

Hi, glad to hear you're still interested; I absolutely do have plans and am currently working on a full rewrite! Unfortunately, I didn't manage to finish it in the semester break which is why it might still take a few month in the worst case (hopefully not). Here are my plans:

• Move away from redux-persist and redux-persist-cookie-storage as the machinery is pretty heavy for the simple task and redux-persist-cookie-storage doesn't seem to be maintained. redux-cookies-middleware seemed to be a good alternative at first, but it has not been maintained for a while now as well. Hence, I'm currently building a tiny custom Redux middleware for the use case. This also allows us to tackle Cookies not being stored properly? state undefined #2 with a warning in dev mode.
• Change the interface: I never really liked the "wrapping next-redux-wrapper" part. It couples the two packages quite tightly. With a custom middleware in place, wrapping the makeStore function is all it takes, I guess.
• The HYDRATE reducer: I think we can make it such that people do not need to alter it for next-redux-cookie-wrapper. Instead, we can do some magic in our middleware:
  • In the getServerSideProps case, we always want the latest cookies from the server to take precedence. We do not have to merge anything as the server also has the client state (ignoring the time between request and response here where the client state might potentially change).
  • In the getStaticProps case, the server does not have client cookies available and incoming state (from the server) in the client can by default be ignored (i.e., the client state remains unaltered). However, there may also be use cases that require custom handling in the HYDRATE reducer, so this must still be possible.

What do you think; any mistakes in my assumptions? If you find something odd or know better alternatives, please let me know! :)

[VictorPulzz]

@bjoluc Thank you for job! One small question, How will you organize the nested persist reducers. I mean the following: let's say we have a store with nested data:

root: {
  user,
  messages
  ... etc
}

Let's say for a user I store data in a cookie.
I messages I store localStorage.
How can I pass this nesting?

[bjoluc]

@VictorPullzz Hey! Well, currently you should be able to use something like

persistConfig: {
    whitelist: ["root.user"],
},

when you call withReduxCookiePersist. I did never try the current version of next-redux-cookie-wrapper alongside a plain redux-persist setup though, nor do I expect that to work. In the next version, however, this should work without any problems since redux-persist is off the next-redux-cookie-wrapper dependencies then. I guess we'll have something like a subtrees config option then where you can add "root.user" to be synced with cookies.

[VictorPulzz]

@VictorPullzz Hey! Well, currently you should be able to use something like

persistConfig: {
    whitelist: ["root.user"],
},

when you call withReduxCookiePersist. I did never try the current version of next-redux-cookie-wrapper alongside a plain redux-persist setup though, nor do I expect that to work. In the next version, however, this should work without any problems since redux-persist is off the next-redux-cookie-wrapper dependencies then. I guess we'll have something like a subtrees config option then where you can add "root.user" to be synced with cookies.

Thanks for answer!
I hope that you will be able to upgrade to the new version of next-redux-wrapper :)
I'm currently trying to connect your plugin and next-redux-wrapper v6, but so far there is little progress :D

[github-actions]

🎉 This issue has been resolved in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀