

Making Flux and REST Play Nicely Together - chanind
https://quizlet.com/blog/629

======
andwaal
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.

~~~
dcqz
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
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.

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

~~~
chanind
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.

~~~
kolemjdouci
Isn't tight coupling one of the code smells?

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

