// 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. |
This comment has been minimized.
This comment has been minimized.
ie- let's say you wanted to test how your userstore reacts to dispatches. without access to the handler, you'd have to initialise a dispatcher and all the other stores (mocked, probably). While this is completely ok, and indeed, is how most flux apps are tested ala jest etc; it's annoying to me :( |
This comment has been minimized.
This comment has been minimized.
I suppose someone who wanted to test stores without all the rest could just export |
This comment has been minimized.
This comment has been minimized.
Let's think about time travel. I want to support this scenario:
These are interesting API-wise, because if the store owns the state and chooses to emit it in response to dispatcher's events, it can't “load” an older snapshot. But if it doesn't own the state, this should be easily doable. Does API need to be tweaked to support this scenario? What would Dispatcher be like? |
This comment has been minimized.
This comment has been minimized.
[it's 430 am, so pardon any hippopotamuses I make] assuming a 'perfect' world, then a rollback is simply a reset + replay of actions till N. actually, to get to any point X -> reset + replay to X. In the app I'm building at work, to get replay working, I had -
so I could do (however, this won't be "real" time travel, because you wouldn't see the transitions in reverse :P I assume that's just fine for now) The dispatcher would have to 'return' something to be used as a snapshot. so you could do - var moment1 = dispatcher.dispatch(someAction, ...args);
// then do a bunch of other dispatches
var moment2 = dispatcher.dispatch(someOtherAction, ...args);
// and then
dispatcher.goTo(moment1);
dispatcher.goTo(moment2); This too shouldn't be too hard to implement, though yeah, it'll take a little bit of internal jiggling on the dispatcher. |
This comment has been minimized.
This comment has been minimized.
Yeah... But. Since we already got that state, why not cache it? (Only in dev, say, for last 500 actions.) It seems to me that one can't achieve a smooth travelling experience if repopulating the stores is |
This comment has been minimized.
This comment has been minimized.
Fair point, just tried with 500 actions and zero delay and it froze hard for a couple of seconds. But then stores would need a .setState() equivalent? Again, doable if only for time travel and not used for anything else. I'm open to alternate implementations. Alternately -
(will get back to this when I wake, but please feel free to keep adding stuff) |
This comment has been minimized.
This comment has been minimized.
What are the usecases for timetravel in stores? Debugging, surely, but what else? Undo/redo? |
This comment has been minimized.
This comment has been minimized.
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.
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. |
This comment has been minimized.
This comment has been minimized.
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 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. |
This comment has been minimized.
This comment has been minimized.
just read the part where dispatcher holds state. good idea, need to think it though.. |
This comment has been minimized.
This comment has been minimized.
export const store = dispatcher.register(initialState, reduceFn); this changes the register signature, but should be easier to do the above now. |
This comment has been minimized.
This comment has been minimized.
Here's something I played with: https://gist.github.com/gaearon/c02f3eb38724b64ab812 |
This comment has been minimized.
one problem I see here is that the stores aren't individually testable unless
handler
is exported as well.