0

Front end clients built using reactjs can appear to modify data but in order for this modifications to persist, the modifications need to be stored on the backend. However, unlike traditional client-server apps, the data being rendered on the client is not being derived from the backend at all times.

For instance, using the classic To-Do app example, given the initial state

(psuedo-code)

To Do List
* Task 1
<input> Add your new task here </input>
<button> Add Task</button>

When the user adds a new task, the client updates the list of task

To Do List
* Task 1
* Task 2
<input> Add your new task here </input>
<button> Add Task </button>

However, the newly added task, "Task 2", is not necessarily in existence on the backend. What are the accepted approaches to push this information back to the backend in order to ensure performance (the client does not have to wait for the round-trip to update) and consistency (if the backend update fails, the user needs to be made aware and can take some kind of action)?

James Montagne
  • 77,516
  • 14
  • 110
  • 130
takinola
  • 1,643
  • 1
  • 12
  • 23

2 Answers2

3

I think the search term that might help you most is "optimistic updates." Basically, you need to keep a record of what request has been made of the server (for instance, "Add 'buy potatoes' to the task list") and whether that request has been fulfilled (successfully or unsuccessfully). I see you tagged this question under Flux, so you may be building a Flux Store to handle API requests.

One pattern I heard described was to build a Store for the Todo items that had two internal data storage areas, one for the confirmed data, and one for optimistic updates. The method responsible for providing data to the React component builds a representation that combines the confirmed data with the updates queue.

When a request succeeds, fails, or times out, an action indicating this result is sent to the item Store. The corresponding item can be added to the confirmed data if the request was a success or removed from the optimistic updates queue if there was an error (hopefully also sending some helpful signal to the user.)

ottonomy
  • 149
  • 1
  • 6
0

From what I understood (But I might well be mistaken, in which case I'm happy to be corrected), inspired by this, a possibility it to have :

  • an Action for when the task is added on the client side
  • a Store that react to this action by creating a "pending", client-side only entity in the model
  • an API method that actually tries to create the object on the server ;
  • if everything goes well, an Action is created to confirm the item has been created
  • the Store react to this by "consolidating" the item on the client side
  • if an error occurs, a different Action is created (and the store should react accordingly, maybe marking the item as "in error", etc..)

I found this was the most "clean" way. Now I find It a bit cumbersome to have to turn :

myAjaxCall().then(function () {
  // everything fine...
} , function () { 
 // some error occured... 
})

Into the creation of three events, handled in different part of the application - So any better solution is interesting.

phtrivier
  • 13,047
  • 6
  • 48
  • 79