Skip to main content

Bug Tracker

Side navigation

#11548 closed bug (wontfix)

Opened April 03, 2012 03:02AM UTC

Closed May 11, 2012 05:35PM UTC

inconsistent parameter order makes $.ajax().always() harder to use than necessary

Reported by: jokeyrhyme Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.2
Keywords: Cc: jaubourg
Blocked by: Blocking:

Please unify the order of parameters between $.ajax(...).fail() and $.ajax(...).then() so that using $.ajax(...).always() is not unnecessarily painful. Even better, please unify the order of returned parameters for all ajax handlers (including success / error / complete options) so that we can end the guess-work. :P

The offending code can be found in src/ajax.js (line 569 in git master):

if ( isSuccess ) {
  deferred.resolveWith( callbackContext, [ success, statusText, jqXHR ] );
} else {
  deferred.rejectWith( callbackContext, [ jqXHR, statusText, error ] );

This means that for AJAX calls, separate .fail() and .then() callbacks need to be created, instead of just being able to do it all in .always(). Combined with the fact that certain result are deemed by jQuery to be failures (e.g. status === 0 for local files), this means we need to have some of our success code duplicated from .then() into .fail().

Example necessary with jQuery 1.7.2:

.fail(function(jqxhr, status, response) {
  if (jqxhr.status === 0) { // for HTML5 Application Cache or local resource
    // TODO: parse response as per data-type
    // TODO: do post-success stuff
  } else {
    // TODO: do post-error stuff
.then(function(response, status, jqxhr) {
  // TODO: do post-success stuff

Example with consistent parameter order (fingers crossed):

.always(function(jqxjr, status, response) {
  // for HTML5 Application Cache or local resource, status === 0
  if ($.inArray(jqxhr.status, [0, 200, 304] !== -1) { 
    // TODO: parse response as per data-type
    // TODO: do post-success stuff
  } else {
    // TODO: do post-error stuff

It was bad enough that the order of parameters is different to the old success / error / complete handlers specified as options to $.ajax(...), but to make them different between resolve and reject makes this extra frustrating.

I understand completely that this breaks compatibility with older versions of jQuery, but I think this is really important for the long-term and worth it. I'm happy to wait for jQuery 1.8 or 1.9 for this breakage to occur. I think it is important to at least discuss this issue on its merits (and I would not have captured them all here in this initial somewhat-emotional post :P).

Please comment.

Attachments (0)
Change History (4)

Changed May 05, 2012 06:30PM UTC by dmethvin comment:1

@jaubourg, thoughts?

It seems like it's way too late to change the jqXHR parameter order. You can .pipe through to a function that reorders the parameters to your liking?

Changed May 05, 2012 06:30PM UTC by dmethvin comment:2

cc: → jaubourg

Changed May 05, 2012 10:02PM UTC by jaubourg comment:3

Backward compatibility nightmare.

You can use pipe to re-order, yes. And you could do that in an ajax prefilter with some trickery if you wanted it for everything.

Changed May 11, 2012 05:35PM UTC by dmethvin comment:4

resolution: → wontfix
status: newclosed

Sorry, I feel your pain but changing things now would make even more of a mess. You can reorder the parameters yourself using a .pipe().