2.0 about redux-persist

[84564221]

The persistStore configuration API should be removed, since it is a pure functional programming anti-pattern.

You don't use configuration to construct your store, you use composition. In that way, you aren't limited to solely the mechanisms thought out ahead of time.

[rt2zz]

@askmatey I have thought about this, and this is more in line with e.g. how redux-localstorage works

The reasoning for the configuration based approach is that it is simple. IMO the alternative is actually not inherently more "functional", it just moves configuration from being an object to being implicit in what you choose to require. It still suffers from limitations of preconceived design.

That said I am entirely open to a more functional pattern, and any api suggestions would be appreciated.

[rt2zz]

Just pushed a first cut at 2.0 to master. Key changes:

Only one REHYDRATE action which now contains the entire stored state tree. No REHYDRATE_COMPLETE action is needed since, REHYDRATE implicitly means rehydration is complete.

All api's are updated accordingly so e.g. persistor.rehydrate now looks like this: persistor.rehydrate(serialState).

I will continue to mess with the api over the next few days. In particular I want to spend some time thinking over the way transforms and serialization happen.

As far as functional composition, I am open to suggestions for how to improve this. I suspect we will always need a configuration object to keep certain basic use cases dead simple e.g. setting the storage engine. That said I suspect there may be some way to expose a functional primitive around transforms and serialization.