Bug Tracker

Modify

Ticket #11548 (closed bug: wontfix)

Opened 2 years ago

Last modified 2 years ago

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
Blocking: Blocked by:

Description

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:

$.ajax('/my/xhr/request.php')
.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):

$.ajax('/my/xhr/request.php')
.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

comment:1 Changed 2 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 2 years ago by dmethvin

  • Cc jaubourg added

comment:3 Changed 2 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 2 years ago by dmethvin

  • Status changed from new to closed
  • Resolution set to wontfix

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

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.