What are the recommended way to do sinks?

[gaearon]

We have a little info on using redux.getState and createRedux(stores, initialState) for rehydrating the data from server, but it would be great to also document the recommended way to do sinks.

For example, one might want to sink a certain store's state to the localStorage, and have that be read on start. In classic Flux, this would be managed by the Store, but in Redux, there is only one Store, and the Reducers are stateless, so they don't seem to be the right place to do it.

I'd say a small doc section showing how you can sink a part of the state tree to some external storage, and read it on startup, would help here.

[heyimalex]

Could be done with... store middleware? This requires the init action to be exposed, but there are other ways I'm sure.

import { INIT_ACTION } from 'redux';

function storageMiddleware(store, key) {
  return function(state, action) {
    if (action === INIT_ACTION) {
      const sessionState = sessionStorage.getItem(key);
      // merge sessionState with state somehow
    }
    const nextState = store(state, action);
    // serialize nextState somehow
    sessionStorage.setItem(key, serializedState);
    return nextState;
  };
}

[acdlite]

@heyimalex Stores are assumed to have no side-effects. Moreover, there's no guarantee of a 1 to 1 correspondence between store calls and change events. E.g. a dev tool may keep track of actions and send them through the store multiple times (reduce them), and only emit a single change event at the end.

The proper way to do side effects is via a subscribed listener. (I'd argue this is best practice in normal Flux, too, though I see people do it all the time.)

[gaearon]

The proper way to do side effects is via a subscribed listener.

👍

[cpixl]

Maybe if the user is able to change how way the final state is handled, this problem could be solved more elegantly, and this could give new capabilities to Redux by deciding how to handle state modification/persistence in a global level inside the application (e.g. local and remote persistence/synchronization of state, debugging, state recording/replay, ImmutableJS on the whole atom).

I believe this already can be implemented by monkey-patching the get/setState by anyone, but... my guess is that it's a bit invasive.

Also, maybe some of these features already can be achieved by using getState()... but I can't imagine how the "time travel" feature could capture all states without using a middleware (where I believe it's not where we should find out if the state was changed).

Anyway... wouldn't a setStateHandler() be an elegant way to modify state persistance (and related things)?

I'm totally new to this library anyway, maybe I'm just talking shit 😋

[cpixl]

It looks like you are already looking for some modifications on the API on #113... just saw it now.

[gaearon]

Yeah, time travel pretty much works locally for me, I'm going to show it off on React Europe conf in about two weeks, stay tuned.

[heyimalex]

@acdlite How about this?

https://gist.github.com/HeyImAlex/0f5ee73e581f64b6c290

It's similar what I use with flummox. Plus you get cross-window/tab syncing. Working off of the Redux described in #113.

[gaearon]

Closing, as not a real issue. We might want to devote a section on this as part of #140.

[rt2zz]

Here is my approach: https://github.com/rt2zz/redux-persist-store

It is working well in my current app, but I would be interested in other approaches. Serialization can be expensive, it would be interesting to experiment with web workers or other delayed processing.