Making Flux and REST Play Nicely Together | Hacker News Reader

Making Flux and REST Play Nicely Together

quizlet.com

20 pointschanind7 comments

I am not sure if I get the point of the ServerModels. One would need to maintain the properties in both the ViewModel and the ServerModel, write logic for syncing them and so on. It also goes against the principle of "one-true-source" of data. I can see that you don`t want to mix up your view-specific properties with your rest-data, but I feel that one might find a better solution for this problem.

On the application I am currently working on we choose the following approach to the problem( were using reflux for Flux implementations, main difference is that actions dispatches them self).

View -> Trigger Action -> Action Creator -> Action creator calls Rest API -> Action sent to Store -> Store receives REST data and creates Immutable versions of it -> Store Triggers immutable version of it`s content to view

This keeps the stores as the "one-true-source" while the action creators does all the communications against the rest-api. Might be that this approach will be to simple when the application is starting to really expand, but I feel we found an easy to maintain, easy to understand and clean solution to the problem.

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.

I 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.

I would really love to see some code snippets with the example mentioned (or ideally an open source project).

The code for this is pretty tightly coupled to the Quizlet codebase right now unfortunately, but I'll work on extracting some sample code soon if there's time.

Isn't tight coupling one of the code smells?

Well, writing code that's too generic or overly abstracted is also a premature optimization...

Reply on news.ycombinator.com