In the modern web application, it’s more common for a page to post forms asynchronously than synchronously using AJAX. Also, it is often more convenient for the user that, rather than reloading the page, parts of it update as inputs are changed or buttons are pressed, such as filtering or sorting a list serverside or fetching a requested record. However, when AJAX does not correctly handle errors on the client or from the server, the page, or at least parts of it, can be left inoperable, making the user unsure whether the page is loading, loaded, or broken. I have a few tips to avoid this. I’ll be using jQuery to make this easy, but if you need to use an old school AJAX callback (or another AJAX-supporting library (if jQuery isn’t permissible (because you (or your customer) are crazy))), the modifications needed are minimal.
Make Your AJAX Respond to the User
Use a spinner for synchronous actions (or a throbber, if that’s your thing)
If a user does something that will require their immediate attention, like opening a modal to edit a model or sorting a list, use something to indicate that the page is communicating with the server. Before showing the spinner, it’s also a good idea to prevent the user from taking any actions you don’t want them to, like resubmitting the form or navigating away. Finally, once the action has finished, successfully or not, you want to stop the spinner. This is best done using .ajaxComplete() globally, as you’ll usually want to take your spinners down whenever the request is finished. If you have multiple spinners on the page which may complete independently, you can use the .always() callback on the jqXHR object locally.
Make Liberal Use of the Error Callbacks
Whenever an error occurs, this is how you handle it. While you will likely want to do custom handling of server errors for each AJAX scenario using .fail(), there are a few defaults with .ajaxError() that you probably want to use, or you can use .ajaxSetup() to set default options for different status codes with the statusCode option. For example, if the server sends back a 500 code, something has gone wrong in a way that the user can’t fix; this is a good place to pop up an alert or a custom error modal informing the user of this and giving them a bug report form or link.
And the Complete Callbacks
This is especially important if an error might leave your page in a state that prevents the user from interacting with it, such as leaving a modal overlay up, or that might give the user bad information, like the spinner not being hidden. On a project where I was using Bootstrap’s modal dialog, not making sure the dialog was entirely cleaned up after an error lead to an error where the modal overlay remained, preventing the user from interacting with the page, but was completely transparent, rather than the normal translucent black, meaning everything looked normal. Don’t make the same mistake I did and succumb to this confusion.
That’s it for these quick tips, folks. If you clean up your AJAX messes and keep it at the lowest level necessary and no lower, your pages should work beautifully.
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at email@example.com. You can also connect with us on Twitter, Facebook, or LinkedIn.