1

We are creating an React application, which has lists with basic CRUD operations in multiple places. The basic example, of course is:

  • Fill input to have name for the item, click submit
  • Send request to server
  • Fire callback on success
  • Update list with item using response data

I want this operation to be fully optimistic:

  • Fill input to have name for the item, click submit
  • Update list with item using given name
  • Send request to server
  • Fire callback on success
  • Update item in the list with response data

So, in the first example we would simply make an item out of the response and update app state. In second example we make the item and when response comes back, we need to find the right item.

The items have id's when they come back from the server. If item has an id, updating, of course, is very simple. The problem with the second example is, that we don't know the backend id for the item.

I have personally solved the issue by giving a frontend id, which is only used for referring to right element on callbacks. Me and my colleagues don't really like the approach, because it is a bit... messy.

What would be an appropriate, efficient pattern for handling this kind of case?

Jaakko Karhu
  • 2,298
  • 4
  • 28
  • 41
  • Your technique sounds like exactly what you need to do. If the ID can't be determined before you save the item, the only thing you can do on the frontend is create the element, keep some sort of reference to it, do the AJAX call, then update that item once you get the response from the server. It doesn't have to be a global variable, you can keep it within the AJAX callback's closure. – Daniel T. Feb 24 '17 at 14:27

1 Answers1

1

First of all I am glad you have found a place for optimistic UI in your project ;)

Concerning your question: what you're doing is indeed a totally valid solution. Setting frontend ID is totally fine. But I, in the similar cases, do it a bit differently. Instead of updating the item on your last step, I would again update the whole list. The point with this is that you get the response with the full list anyway so why not to use it? It solves two issues:

  • no need to rely on frontend ID or any other way of marking/storing the item for that matter;
  • in case there is a possibility of multi-threaded updates to the list from different clients (in the timeframe between your client gets the list and clicks submit), updating the whole list will keep it up-to-date much better;

Note though that updating a large list might have an impact on performance after all. At the same time, you don't need to parse the list after getting the response so you save some time here.

So compare both solutions and make a decision based on the best possible outcome for your users ;)

spliter
  • 12,321
  • 4
  • 33
  • 36