Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#10209 closed bug (invalid)

Intentional: $.get & $.post may have the arguments passed in a way that the callback will not be the last argument

Reported by: joe@… Owned by: joe@…
Priority: low Milestone: None
Component: ajax Version: 1.6.3
Keywords: Cc:
Blocked by: Blocking:

Description

John Resig has highlighted the importance of API consistency numerous times. As an example, he says that jQuery is set up to ALWAYS take the callback function as the last parameter.

However, $.get & $.post can both get a "dataType" parameter after the callback (all the way back to jQuery 1.0). Although this is not practically a bug (since this is intentional) it is against the API consistency theory.

Change History (8)

comment:1 Changed 7 years ago by Rick Waldron

Component: unfiledajax
Owner: set to joe@…
Priority: undecidedlow
Status: newpending

So, are you suggesting that jQuery should break compat all the way back to 1.0? Or should we try John for heresy?

comment:2 in reply to:  1 Changed 7 years ago by anonymous

Replying to rwaldron:

So, are you suggesting that jQuery should break compat all the way back to 1.0? Or should we try John for heresy?

Of course not. While some have called me mad, I've yet to be titled lunatic.

All I'm proposing is to add the option to pass the dataType before the success callback. Since dataType is always a string and the success callback is always, well, a function (and risking the Dunning–Kruger effect), this should be pretty easy to implement.

comment:3 in reply to:  description Changed 7 years ago by anonymous

Replying to joe@…:

John Resig has highlighted the importance of API consistency numerous times. As an example, he says that jQuery is set up to ALWAYS take the callback function as the last parameter.

However, $.get & $.post can both get a "dataType" parameter after the callback (all the way back to jQuery 1.0). Although this is not practically a bug (since this is intentional) it is against the API consistency theory.

Here's my proposed fix:

 // allow for callback to be passed in as last argument
if ( jQuery.isFunction(type) ) {
   var tempType = callback;
   callback = type;
   type = tempType;
}

comment:4 Changed 7 years ago by Rick Waldron

As long as your content-type headers are correct in the server's response, jQuery will handle the dataType for you, which means you wouldn't need to define that param anyway...

Last edited 7 years ago by Rick Waldron (previous) (diff)

comment:5 in reply to:  4 Changed 7 years ago by anonymous

Replying to rwaldron:

As long as you're content-type headers are correct in the server's response, jQuery will handle the dataType for you, which means you wouldn't need to define that param anyway...

I don't understand what you're trying to say. jQuery does support incorrect content-type headers (by setting the dataTpe), and the API should be consistent with the rest of jQuery.

Are you proposing to get rid of the dataType argument altogether?

comment:6 Changed 7 years ago by Rick Waldron

certainly not... I just think this is a completely unnecessary change.

comment:7 Changed 7 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

comment:8 in reply to:  7 Changed 7 years ago by joe@…

Replying to trac-o-bot:

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

I truly believe that this should be addressed, since it's such an easy fix.

I've done all the work, and modified the above solution to take into account all possible scenarios ([url, data, dataType, success], [url, dataType, success] & [url, non-primitive dataType, success]).

I created a fiddle with the code, as well as a test for all variations possible (also showing that there's no regression): http://jsfiddle.net/afC5g/1/

Note: See TracTickets for help on using tickets.