Bug Tracker

Opened 8 years ago

Closed 8 years ago

#9098 closed enhancement (wontfix)

jqXHR.pipe should retain success and errror

Reported by: sahab.yazdani+jquery@… Owned by:
Priority: undecided Milestone: 1.next
Component: unfiled Version: 1.6
Keywords: Cc:
Blocked by: Blocking:

Description

Try the following code snippet:

var jqXHR = $.ajax(url_1).pipe(function(r) {

return $.ajax(url_2);

}); alert(jqXHR.success + ' ' + jqXHR.error);

Actual Result: 'undefined undefined' Expected Result: 'function function'

The reason is that the new pipe function is on the base Defered object and does not know about the aliases that sets up (success => done, error => fail).

Change History (2)

comment:1 Changed 8 years ago by dmethvin

My feeling on this is that .success and .error were added primarily as compatibility crutches because the ajax callbacks had the same name. If you're using .pipe you don't need those crutches, and it just clutters things to keep passing them down the line.

But I defer (haha) to jaubourg.

comment:2 Changed 8 years ago by jaubourg

Resolution: wontfix
Status: newclosed

The way success and error made it onto the jqXHR is a weird story. Fact is success and error were put on the jqXHR object before Deferred were extracted out of the ajax code. While working on Deferred, we went for more generic names.

I think we should advice people to use done and fail, not success and error. I'd like to have the success, error and complete methods deprecated in 1.7 and removed in 1.8. In retrospect, it was somehow a mistep to introduce them in the first place. I like to think it was a necessary step to make people aware of Deferreds in some kind of natural and familiar fashion, but that's just wishful thinking from someone who clearly didn't think far enough.

To get back to the feature request at hand, pipe is aware of what the callback method returns only (if and) when the ajax request is successfull, so it cannot guess if it'll be a jqXHR object in advance (pipe actually creates a Deferred internally and does not return what the callbacks return directly). It's perfectly possible to have some logic in the callback and return different things depending on the resolve value.

Note: See TracTickets for help on using tickets.