Investigate replay-based rehydration about dispatchr HOT 8 OPEN

I think is not the way to go since you retrieve a snapshot from the server. A Get req gives you a snapshot image.

And rebuild state then should be done with closer to the snapshot than try to run through a chain of effects IMHO. It will be very hard in the local what is event handler vs what shall execute business logic ect.

Plus as you said the overhead will be big for the sake of none.
When the ui has rendered all the event handling should be up as soon as possible.

from dispatchr.

Rehydrtaion of stores through replay will bring it much closer to event sourcing ideas. We are currently experimenting with replay and it works well. There are only a handful of events being replayed so performence has not been an issue. It would definitely be great to see support for that directly in the library.

from dispatchr.

Yeah, I think it depends on the application, so it could be a configuration option. The implementation should be fairly simple. I'm totally willing to add this in if someone wants to do a PR.

from dispatchr.

If the dehydrate / rehydrate methods won't go away what's the purpose ?

The goal was to reduce code right so in that case I would say there should be a single way to do the state mgmt on client side init.

But hey I'm a purist and like simplicity.

On 17 Feb 2015, at 23:06, Michael Ridgway [email protected] wrote:

Yeah, I think it depends on the application, so it could be a configuration option. The implementation should be fairly simple. I'm totally willing to add this in if someone wants to do a PR.

—
Reply to this email directly or view it on GitHub.

from dispatchr.

The need for each store to define dehydrate/rehydrate would go away. With replay, it would just re-dispatch the events on the client.

from dispatchr.

Right, It felt like you wanted both. I could def see the benefit by having a self solving rehydration.

from dispatchr.

Could we add an standard dehydrate / rehydrate to the BaseStore? Those methods could just set/get this.state which is what is done in most cases.

from dispatchr.

Elegant idea. Either that or a mixin would work.

from dispatchr.