Skip to content
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

Open
clinuz opened this issue Aug 26, 2016 · 5 comments
Open

Transform ordering, restore subset with defaults #1

clinuz opened this issue Aug 26, 2016 · 5 comments

Comments

@clinuz
Copy link

clinuz commented Aug 26, 2016

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!

@edy
Copy link
Owner

edy commented Aug 26, 2016

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

@clinuz
Copy link
Author

clinuz commented Aug 29, 2016

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.

@edy
Copy link
Owner

edy commented Aug 29, 2016

i'll tinker around the next days and will get back to you later with my results

@micnil
Copy link

micnil commented Nov 12, 2017

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.

@alexeychikk
Copy link

@micnil Thanks a lot! Using persistCombineReducers instead of combineReducers fixes the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants