sto alternate api

gistfile1.js

// store.js
let {store, handler} = sto(initialState, reduceFn);   // where reduceFn: function(currentState, action, ...args){}

dispatcher.register(handler);
export store;

// elsewhere
store.get()  // -> current state

store.toObservable() // -> to be used with .observe()

// that's it.  

But then stores would need a .setState() equivalent?

Why? If they don't own state and only tell how to compute it, maybe “dispatcher” has the power to give components some older state of all stores instead of the current state.

What are the usecases for timetravel in stores?

Debugging, for sure. Now that I'm thinking of it, I also want to support restore-from-JSON and serialize-to-JSON. Which doesn't usually work well with Flux —but— our Stores don't need to own the state. The may just specify calculation. If dispatcher holds state and uses stores to reduce it and “advance” it, it can hold it in a single tree internally and snapshot/restore/rollback to any point.

But that's the thing, they do own it. Specifically, they hide it. Like an observable; you can't set the 'current' value to operate on. To get around this you'll need a .setState(), at least exposed to the dispatcher.

Alternately, yes, the dispatcher/view controller could bypass all that and load cached state. But then you can't fire further actions until you get back to where you came from.

just read the part where dispatcher holds state. good idea, need to think it though..

export const store = dispatcher.register(initialState, reduceFn);

this changes the register signature, but should be easier to do the above now.

Here's something I played with: https://gist.github.com/gaearon/c02f3eb38724b64ab812
Let me know your thoughts!