1

What's a sustainable, consistent and logical way to deal with Reflux actions that commit a number changes that have only been made locally to a remote source?

The unidirectional dataflow makes perfect sense if user interaction always (or never, as in most tutorial examples) gives rise to remote changes. A typical case:

  • The user enters a value into a field, which triggers an action (e.g. CommentActions.setTitle(title))
  • The action makes a remote call, and upon success triggers the CommentActions.setTitle.completed(title) child action
  • The store listens through e.g. CommentStore#onSetTitleCompleted(title), and changes its state
  • A component is re-rendered reflecting the new state (e.g. state.title).

Another way to put this might be that every modification to the local store is mirrored by a change in the remote store. However, for various reasons, this is not always desirable. In a lot of situations, it makes sense to only call the server once editing is complete, e.g. upon pressing a "Save" or "Post" button.

I can see this happening in a multitude of situations. For example, without knowing the implementation details, it seems likely that when creating events on Facebook, all data (date, title, description, guest list etc.) is stored locally until the user hits the "Create Event" button.

It seems logical to introduce an action like CommentActions.postComment(), but that creates a difficulty: there is no obvious way for the action to access all the data that has been supplied and edited to that point, unlike the first case where each action is fed the data subject to change (e.g. the title).

The best way I've come up with so far is to make the component responsible for feeding the right data to the action. The local values are held in the store, and are thus accessible to the component through mixing in of state. When it's time for the final save, it's triggered by e.g. CommentActions.postComment(this.state.title, this.state.body, this.state.email, ...).

I suppose there are many solutions involving eschewing the Flux flow (e.g. having the store call actions) but I'm primarily interested in solutions that don't break the very foundational principles of the library :)

Sagar V
  • 12,158
  • 7
  • 41
  • 68
Hannes Petri
  • 864
  • 1
  • 7
  • 15
  • I am upvoting this because it is well explained. I didn't read though. From a new user, it is very good post. - from review – Sagar V Jun 13 '17 at 09:00
  • I don't understand the issue in keeping the states in your COMPONENT for all the data that needs to be sent to your STORE via ACTIONS? That way, you can simply create an object of all the required states in some JSON format u want, and simply pass as one parameter. – Ankush Raghuvanshi Jun 20 '17 at 14:04

0 Answers0