imgres

Dealing with ajax has become so easy and high-level that it is pretty easy to forget about the details. A nice habit to get into when dealing with an ajax-heavy frontend is to manage the event listeners and connections that a user can initiate.

Something simple to remember is that you can’t rely on your requests to complete FIFO because your requests are getting routed across multiple processes/machines that may or may not be under load. Alot of users are rather click-happy (my mom still double-clicks links) which can lead to problems with content that was requested on the first click being loaded after the content from the most recent click.

In the past I have always included sequence numbers as request ID’s and then have the server include the request ID it is responding to in the JSON response. This gives the event handlers some context of the response it just received in relation to the most recent action the user has performed on the page.

This works well, but sometimes you just want to throw out any response that is not in response to the most recent request. This is where the abort() method is useful.


var current_conn;

function getSome() {
if(current_request) {current_request.abort();}
current_request = $.get('/events',
{ team : "Ramrod" },
function(resp) { alert(resp); }
);
}

If you need to, you could use the sequence number approach and create a response queue or other more complex solution. Here are a few neat ideas as well…

http://www.protofunc.com/scripts/jquery/ajaxManager/

How to Deal With $.ajax abort()

Leave a Reply