2.0

[rt2zz]

• move serialize/deserialize responsibility into storage engine
  • how to handle AsyncStorage?
• consider defaulting to localForage
• single rehydrate action
• evaluate what top level immutable support looks like
• consider removal of rehydrateAction and completeAction
• should persistor.rehydrate accept "serialized" payload or should deserialization be a responsbility of the caller?
• buffer actions:
  • can we avoid dispatching REHYDRATE_COMPLETE when skipRestore: true
  • how should buffer actions work if there are multiple persistors
• do we need a coordinated factory so that autoRehydrate and persistStore can share state/config?
  • i.e. let {persistStore, autoRehydrate} = createPersistScheme(config)

[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.