*applause*

I would suggest to present this method as a shorthand method like

jQuery.get|post|getScript

. And therefore do not rename "cache" or "type" options but change signature of "beforeSend" for jQuery.ajax too.

"expose localProtocols as a global config array instead" and "eventually it should be possible to build jQuery with just this interface" should have different tickets

Replying to [comment:4 markelog]:

I would suggest to present this method as a shorthand method like

jQuery.get|post|getScript

. And therefore do not rename "cache" or "type" options but change signature of "beforeSend" for jQuery.ajax too.

But it's not a shorthand method. It's a complete replacement of jQuery.ajax() and having lots of parameters is a bad API.

"expose localProtocols as a global config array instead" and "eventually it should be possible to build jQuery with just this interface" should have different tickets

Except that it's not possible to build this as it's intended without those. The goal is to leave jQuery.ajax() as-is and create a new, leaner, simpler API.

It's a complete replacement of jQuery.ajax()

It could not be a "complete replacement" of

jQuery.ajax

since it does not presented with same functionality, like you couldn't use

jsonp

or

script

transports and it does not give any alternatives for them (and it shouldn't given method's name), you couldn't use

$.getJSON

as a shorthand method for

jQuery.xhr

since you have to do the conversion yourself and so on – list could continue.

having lots of parameters is a bad API.

No arguments there.

Except that it's not possible to build this as it's intended without those

Not quite,

localProtocols

as a global config, could be implemented first and

jQuery.ajax

could start using it.

As for build option – you obviously need to implement this method first, which is this task purpose and only then you could make it a build option, hence word "eventually" in the quote.

The goal is to leave jQuery.ajax() as-is and create a new, leaner, simpler API

You could achieve that if

jQuery.xhr

would be presented as shorthand and

jQuery.ajax

would be considered a last resort method. I fear if we choose the other route it could lead to source of confusion.

Replying to [comment:6 markelog]:

It could not be a "complete replacement" of

jQuery.ajax

since it does not presented with same functionality

This is just a misunderstanding of the wording. It's not a replacement for the complete functionality of jQuery.ajax(). It's a complete replacement in the sense that jQuery.ajax() is removed and jQuery.xhr() is added. One of the main goals is to completely get rid of jQuery.ajax(), which is why jQuery.xhr() can't be a shorthand method.

Not quite,

localProtocols

as a global config, could be implemented first and

jQuery.ajax

could start using it.

I suppose, but I don't think there are any plans to change the APIs around jQuery.ajax(). The proposed path is not to touch jQuery.ajax() at all.

> The goal is to leave jQuery.ajax() as-is and create a new, leaner, simpler API You could achieve that if

jQuery.xhr

would be presented as shorthand and

jQuery.ajax

would be considered a last resort method. I fear if we choose the other route it could lead to source of confusion.

I'm not sure what the source of confusion would be, but I'm happy to talk through any potential confusion. If you're using jQuery.xhr(), you shouldn't be using jQuery.ajax(). The docs would make this clear.

completely get rid of jQuery.ajax()

Oh my, even if

jQuery.xhr

could have same functionality that

jQuery.ajax

has, but with better API,

even then, it would be... bold i guess, even just to deprecate

jQuery.ajax

.

The proposed path is not to touch jQuery.ajax() at all.

Designation of what

localProtocols

are, made inside ajax module, which is not a public API, consequance of

jQuery.xhr

introduction is, as it said in ticket description, to make it a public property.

How to expose it (

jQuery.ajaxSettings

? What format?) is a question that i would recommend to dealt before

jQuery.xhr

implementation, because it would affect

jQuery.ajax

.

Just like

convertors

option that could be passed to

jQuery.ajax

and is defined in

jQuery.ajaxSettings

The exposure of localProtocols doesn't have to affect jQuery.ajax(), but it can, if we want it to.

I would expect that jQuery.ajaxSettings wouldn't be used at all in jQuery.xhr(). Changing the actual default values for Ajax requests seems really bad to me.

There should definitely not be a way to change the default settings, since that has the potential to create havoc in a modular app just like jQuery.ajaxSettings does.

It would also be good to clearly document for each method whether the data is sent on the URL or alternatively in the content body. There is some ambiguity about whether methods like DELETE can have a body or not as I recall, there's a ticket around here somewhere.

The ticket description outlines the options to keep, though we should consider adjusting some of those as well. Angualar's $http service seems like a good reference. Specifically, they avoid the confusion of data by having a separate params option: params get appended as query string, data as message body, without any ambiguity.

Another aspect to consider is the response object. Angular puts 'data', 'status', 'headers' and 'config' properties on a single response object, in order to fit it into a promise.

Yehuda mentioned this code, which (among other things) adapts $.ajax to an rsvp.js Promise which is Promises/A+ compliant:

https://github.com/instructure/ic-ajax/blob/master/main.js

#15053 is a duplicate of this ticket.

Migrated to https://github.com/jquery/jquery/issues/1713