-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transform ordering, restore subset with defaults #1
Comments
hi, thank you for creating the first issue :-) i set up an example repository which shows how one would use the filter transform: https://github.com/edy/redux-persist-transform-filter-example only the counter is persisted in the session store and is restored on every page refresh. as you can see in the screenshot, the counter is merged with the initial store. i never worked with immutables before. please let me know if i could help you |
Hi @edy thank you for the quick and helpful response! It looks like the issue is which initialization path you take when setting up the store. If you use |
i'll tinker around the next days and will get back to you later with my results |
I ran into this issue with version 5 of redux persist. The filter transform was doing its job correct, but the initial state for the values that were not saved were overwritten to The problem was that I was using the method Read more about it here. |
@micnil Thanks a lot! Using |
Hi, this transform is great! Hopefully there is a solution that I'm just missing but it seems to me if you are only storing a subset of your reducer's state, on restoration of said data you'll be missing the other keys.
In the case I'm seeing, I have initial state available before localForage has been returned. Since it is only restoring a subset of my keys, it blows away the initial values of the non-stored keys.
Of course I could move the non-stored keys to another reducer but this doesn't make logical sense from the app perspective. It would also remove the usefulness of this transform for this use case. I could also have the reducer check to see if all keys are present and merge defaults if they aren't but this simple check would happen far too often when it only needs to happen once.
I doubt this is too far fetched to come up in other situations. Any guidance would be appreciated.
Also, this transform does not appear to work if placed after the immutable transform. I haven't seen that documented anywhere but I might have missed it. Thanks!
The text was updated successfully, but these errors were encountered: