Time travel

[gaearon]

Reviving musings from #6, I'm going to post my progress on working on time travel & other devtool goodness here.

I have a working proof of concept of time travel that uses the default dispatcher and relies on store composition to keep a log of state. This is not feature-complete (only “jumping to state #N” is supported), but shows how to implement such functionality with Store composition:

export const StateKeys = {
  LOG: Symbol('Log')
};

export const ActionTypes = {
  JUMP_TO_STATE: Symbol('JUMP_TO_STATE')
};

export default function recorder(store) {
  return function Recorder(state = {}, action) {
    let { [StateKeys.LOG]: log = [], ...atom } = state;

    let nextAtom;
    switch (action.type) {
    case ActionTypes.JUMP_TO_STATE:
      const { index } = action;
      nextAtom = log[index].nextAtom;
      break;
    default:
      nextAtom = store(atom, action);
      break;
    }

    log = [...log, {
      action,
      atom,
      nextAtom
    }];

    return {
      [StateKeys.LOG]: log,
      ...nextAtom
    };
  }
}

Usage:

const store = composeStores(stores);
const dispatcher = createDispatcher(recorder(store)); // wrap the store
const redux = createRedux(dispatcher);

This relies on the root atom being “normal” a JS object though. I think we'll need to store it internally as atom field instead inside a plain JS object created by us to support such “hidden” tool state.

I'd accept a PR that hides the user store's state inside an atom field on the Redux instance's state object, at the same time preserving the current API and behavior exactly. Redux.getState() should keep retuning that atom. Any other fields on the internal state will be assumed to be only used by the devtools.

[acdlite]

Hmm, why would the state live on the Redux instance? Didn't we decide that the true state "lives" inside the dispatcher?

[gaearon]

Hmm, why would the state live on the Redux instance?

It's currently inside this.state on Redux instance so that anyone can dehydrate it (getState()) and so components can ask the current state. Indeed, it's just a copy of the real state held inside the dispatcher.

The dispatcher is given setState callback precisely to set that state field (and let the world know it has changed).

[acdlite]

Indeed, it's just a copy of the real state held inside the dispatcher.

Exactly, so if the true state lives inside the dispatcher, why does meta state need to leak out to the Redux instance at all? Can't it be completely self-contained?

[gaearon]

Dispatcher needs to be completely replaceable at any point of time for hot reloading. If it doesn't fully yield its state to the Redux instance “for keeps”, the next dispatcher won't receive any hidden fields on hot reload.

[acdlite]

Okay, that makes sense. But in that case, I think the dispatcher should be completely stateless, and we pass it a getState() function rather than having a separate copy of the state atom, which is confusing and bug prone.

[acdlite]

So then the state would live completely on the Redux instance and nowhere else.

[acdlite]

To summarize what I'm proposing:

createRedux({
  dispatcher: (getState, setState, dispatch) =>  {...} // returns a pure dispatch function, no state
  prepareState: (rawState) => {...} // returns state prepared for consumer, stripped of "meta"
})

Ignore the particulars of the API and just focus on the inputs and outputs

[gaearon]

I was worried getState might give the impression that the state might somehow change outside without dispatcher's knowledge which isn't true. But perhaps you're right this API makes more sense.

What is the dispatch argument for? Middleware?
I thought you were proposing (getState, setState) => (action) => ().

[acdlite]

I thought you were proposing (getState, setState) => (action) => ().

I am, just put dispatch() in there as well for, yes, middleware. Should bring it up in a separate issue, but the problem right now is (to use the default middleware as an example) there's no way to do a truly recursive dispatch:

export default function thunkMiddleware(getState) {
  return (next) => {
    const recurse = (action) =>
      typeof action === 'function' ?
        action(recurse, getState) :
        next(action);

    return recurse;
  };
}

recurse() will recursively call the current middleware, but not any that were executed before it in the chain.

[gaearon]

Can you PR your proposed changes when you get some time?

[acdlite]

Sure, I will tonight

[gaearon]

Thank you! I really like where this is going 🎉