Bug Tracker

Opened 5 years ago

Closed 5 years ago

#11548 closed bug (wontfix)

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.

Change History (4)

comment:1 Changed 5 years ago by dmethvin

@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?

comment:2 Changed 5 years ago by dmethvin

Cc: jaubourg added

comment:3 Changed 5 years ago by jaubourg

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.

comment:4 Changed 5 years ago by dmethvin

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().

Note: See TracTickets for help on using tickets.