4 ms·
I think that's a valid approach as well. The server models are there as a way to resolve differences between the state of the models in the view and the state o
by dcqz 12y ago
I think that's a valid approach as well. The server models are there as a way to resolve differences between the state of the models in the view and the state of the models in the server. It's nice if, for instance, the users loses internet connection and then comes back online we can intelligently figure out what's different between the client and server and sync those changes. Another situation is if we want to intentionally let the client state drift from the server state temporarily. For example, add, remove, and update models in the UI without having them be synced to the server immediately (ex. maybe they can make a bunch of changes and then press "SAVE" to fully persist or "CANCEL" to revert). It's particularly useful for apps where there's a lot of modification do data rather than just displaying data, but there's certainly other valid ways to approach the problem.
- andwaal 12y agoI do see a that one use-case might be your scenario where one user loses internet connection and comes back online. But this is just valid in cases where multiple users work on the same set of data and in those cases one suddenly got a more complex scenario(where one probably would need some kind of notification system, sockets, long-polling etc, to notify one user that another one has made a change). In a case with lots of data modifications and a final step of "SAVE/CANCEL" whats your reason for not just keep the "current offline state" in the viewmodel-store and submit these when the user clicks SAVE?(If the user clicks CANCEL on can just reload the initial state from the REST service). This would perform the same task with lots of complexity removed. But if you have discussed all the possible problems above, whats your strategy for keeping the server/view-models properties in sync? Seems like a lots of work just handling that.