Open clinuz opened 8 years ago
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 it's an create-react-app and is very rough. it works though.
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 persistStore
like you did in your example, yes, it works fine. If you instead use the alternate path (https://github.com/rt2zz/redux-persist#alternate-usage) it will not work because when the store is generated the initial state exists and defaults will not be applied. I'm not sure if this is intended or just not documented (in their docs). At the very least, this is the behavior I'm seeing.
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 undefined
.
The problem was that I was using the method persistReducer(persistConfig, rootReducer);
where rootReducer was created with redux combineReducers
. Instead you should create the rootReducer using the recommended persistCombineReducers(persistConfig, reducers)
, where reducers is just an object with all reducers.
Read more about it here.
@micnil Thanks a lot! Using persistCombineReducers
instead of combineReducers
fixes the issue.
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!