Any plans on updating this library to newest wrapper version?
MaciejWiatr opened this issue ยท 5 comments
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?
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
andredux-persist-cookie-storage
as the machinery is pretty heavy for the simple task andredux-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 #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 themakeStore
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 theHYDRATE
reducer, so this must still be possible.
- In the
What do you think; any mistakes in my assumptions? If you find something odd or know better alternatives, please let me know! :)
@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?
@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.
@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 ofnext-redux-cookie-wrapper
alongside a plainredux-persist
setup though, nor do I expect that to work. In the next version, however, this should work without any problems sinceredux-persist
is off thenext-redux-cookie-wrapper
dependencies then. I guess we'll have something like asubtrees
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
๐ This issue has been resolved in version 2.0.0 ๐
The release is available on:
Your semantic-release bot ๐ฆ๐