1

When developing web applications I generally see two ways people perform crud and sync the view.

Here are the high level examples which use ajax.

1- Method one

A create operation could involve a POST request and on success of that just do another GET and fetch all the data and rerender you view.

A delete operation is similar just do another GET on delete success

2- Method two

A create operation could involve a POST request which would return just the inserted id and on success of that do NOT do another GET request rather append the data that was just was sent into the current list of items in your view.

A delete operation would return the id and on success search the element that has that id and delete from DOM or array of items etc.

I am interested to know what is usually more preferable, method two for example saves a GET request but it comes at a lot of complexity in the front-end code as now you have to write the code the figures out which item needs to be delete updated etc and if the server needs to add more data to the item that was created before it is displayed this will make method two harder. On the other performance will be better if the GET requests takes a long time to load.

In my projects depending on the complexity I may use either method depending on the situation but I do believe it's better to stick with one approach.

ericsicons
  • 1,475
  • 3
  • 23
  • 38
  • One of the key things to think about is concurrency - if there is a likelihood of more than one person working on the same data you're better off getting it again. Also, will you be doing any lookups, validation or calculations on the server, if so then you should get from the server too. There are many other factors, and you mentioned a couple of important ones - complexity and perceived user performance. I would say that if you choose to do more on the client - don't ever trust what you get from the client, assume it has been tampered with and validate it! – SeanN Dec 24 '15 at 05:10

1 Answers1

1

Go with method 2. Manipulate your HTML as soon as the user requests the action. Your users expect whatever action they take on your page to have immediate feedback. You can't afford to wait a quarter of a second to a full second waiting for your back-end to respond before you provide this feedback. If you do, the user will most likely try the action again - this is just a natural instinct all users have today.

This brings up the question: what if my operation doesn't succeed and is rejected by the back-end? You should also write your code so that on error response, you are undoing the view changes you made when the initial action was detected and that you are providing a message (whether showing a bright DIV error box or alerting the user through a pop-up) to the user that their action did not complete successfully.

This gives you the best of both worlds. Your user gets a smooth UI experience, and you provide a way of informing your users if their requests are rejected.

Here's an example of how you would write this using jQuery. But this technique applies to any JavaScript framework (Backbone, Angular, etc...)

$('#button').on('click', function(){
    //do some DOM changes that tell my user their action succeeded
    $.ajax({
        url: 'http://myendpoint.com',
        type: 'POST',
        data: {key: 'value'},
        error: function(){
            //undo my DOM changes since request failed
        }
    });
});
Lloyd Banks
  • 35,740
  • 58
  • 156
  • 248