dispatchr
dispatchr copied to clipboard
YahooArchive
Investigate replay-based rehydration
Theoretically, stores could be reset to their original state by recording the actions and payloads that were dispatched on the server, serializing them, and then replaying them on the client to rehydrate the application. An investigation on the performance and implementation benefits for each should be done.
This could reduce the amount of code in each store since they would no longer need to implement dehydrate/rehydrate functions.
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.
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.
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.
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.
The need for each store to define dehydrate/rehydrate would go away. With replay, it would just re-dispatch the events on the client.
Right, It felt like you wanted both. I could def see the benefit by having a self solving rehydration.
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.
