Bug Tracker

Ticket #9399 (closed enhancement: fixed)

Opened 4 years ago

Last modified 22 months ago

Deprecate jqXHR.success and jqXHR.error

Reported by: jaubourg Owned by: jaubourg
Priority: blocker Milestone: 1.8
Component: ajax Version: 1.6.1
Keywords: 1.7-discuss Cc:
Blocking: Blocked by:

Description

Deprecate jqXHR.success and jqXHR.error and start pushing users into using jqXHR.done and jqXHR.fail. jqXHR.complete is a bit more complicated seeing as Deferred.always is not a direct equivalent to it. Goal is to remove jqXHR.success and jqXHR.error in 1.8.

Change History

comment:1 Changed 4 years ago by john

  • Keywords 1.7-discuss added

Nominating ticket for 1.7 discussion.

comment:2 Changed 4 years ago by rwaldron

+1,

comment:3 Changed 4 years ago by jaubourg

+0, I suggests this but I have no firm conviction regarding it... hence why I ask you guys

comment:4 Changed 4 years ago by timmywil

+1,

comment:5 Changed 4 years ago by timmywil

  • Priority changed from undecided to low
  • Status changed from new to open
  • Component changed from unfiled to ajax

comment:6 Changed 4 years ago by dmethvin

+1, This is a quick deprecation, we shouldn't have added it. But I agree it's a mess to retain it, let's document it immediately but leave it in for a while.

comment:7 Changed 3 years ago by john

+0

comment:8 Changed 3 years ago by addyosmani

+0

comment:9 Changed 3 years ago by ajpiano

-1, Doesn't make sense to me that users should have to use the word "success" if they're using an options object to $.ajax but .done if they're subscribing to the $.ajax Deferred-style. (Same for error/fail)

comment:10 Changed 3 years ago by danheberden

+1, please please please

comment:11 Changed 3 years ago by scott.gonzalez

-1, the name success is all over the place for ajax, we should keep these

comment:12 Changed 3 years ago by dmethvin

  • Priority changed from low to blocker
  • Milestone changed from 1.next to 1.7

comment:13 Changed 3 years ago by dmethvin

  • Keywords needsdocs added

comment:14 Changed 3 years ago by addyosmani

  • Keywords needsdocs removed

comment:15 Changed 3 years ago by john

  • Owner set to jaubourg
  • Status changed from open to assigned

comment:16 Changed 3 years ago by jaubourg

  • Status changed from assigned to closed
  • Resolution set to fixed

This is documented as deprecated already so I'll consider this fixed... unless we wanna keep track of this for removal in 1.8?

comment:17 Changed 3 years ago by flipace

Where can I find information about - why - these got deprecated?

comment:17 Changed 3 years ago by flipace

Where can I find information about - why - these got deprecated?

comment:18 Changed 3 years ago by anonymous

Not only why, but why the documentation examples still use success, error, and complete. Deprecating this is 1.7 and removing in 1.8 doesn't give enough time. These shouldn't be removed until at 1.9 or later. Or at the very least, alias success, error, and complete to done, fail, always for backwards compatibility.

comment:19 Changed 3 years ago by anonymous

Absolutely concur with commentor 18. The success, error,and complete handlers should be aliased for backward compatibility for an extended period, if not indefinitely. I shudder to imagine the number of unhappy users which would be uncovered by their removal.

comment:20 Changed 3 years ago by anonymous

-1

Don't go changing names just because you don't like them.

comment:21 Changed 3 years ago by anonymous

Docs updated?! The page does not even have these new names in main settings list. Some obscure mention in a semi-random place is not enough. To say the truth whole page is rather incomprehensible, so could be you were just following tradition.

comment:22 Changed 3 years ago by ajpiano

That's because the 'settings' options have not and will not change, only the $.ajax().success() $.ajax().error() etc, aliases to done, fail, always, which will be available in 1.7 and deprecated in 1.8. This is a relatively new API anyway (1.5) and keeping these aliases around in perpetuity is unwise.

comment:23 Changed 3 years ago by anonymous

Yay, this will only break ALL MY WEBSITES!

comment:24 Changed 3 years ago by eli@…

@ajpiano Is there a roadmap for when the removal of these methods are planned to take place?

comment:25 Changed 3 years ago by SlexAxton

Upon removal, could we release a compatibility plugin to re-alias these for people who don't understand how that would work themselves? Shouldn't be too difficult...

comment:26 Changed 3 years ago by dmethvin

I agree we could do a better job at publicizing the logic behind these changes, and we will in the future.

Note that this change isn't intended to remove any functionality, it just removes the aliases that we put on the Deferred object returned by $.ajax so that it uses the standard Deferred names. It should be possible to move to the new names via a simple text replace in most cases.

@eli, no there is not a roadmap for removal in general. We are deprecating things to indicate that they are not the best-practice way to do something in jQuery. It's possible that things that are deprecated are *never* removed, but then again we are unlikely to add features to it or fix bugs in a feature like that.

success, error,and complete handlers should be aliased for backward compatibility for an extended period, if not indefinitely

Agreed about the extended period. Note, however, that even if we wait five years there will be people who have not changed their code. Deprecation is the start of the notice we need to give if we are ever to have a hope of removing something.

In the meantime, nothing prevents anyone from using the features marked deprecated in 1.7, including this one. We will start a separate (and more visible) thread about the direction of jQuery once 1.7 has shipped.

could we release a compatibility plugin

That has been suggested and would most likely be our approach for many of these things in the 2.0 time frame.

comment:27 Changed 3 years ago by anonymous

I think the document should clearly indicate the $.ajax() option names of success etc are not changed. I got the impression that they may also changed reading the 1.7 docs, and couldn't find clear answers in the doc itself.

comment:28 Changed 2 years ago by dmethvin

  • Milestone changed from 1.7 to 1.8

This deprecation notice is being moved to 1.8, since the docs indicated it was to start then despite this ticket.

The reason these were deprecated is that they create an unneeded special case for the Deferred returned from an XHR.

comment:29 Changed 22 months ago by anonymous

This change does not include the $.get and $.post methods, right?

Note: See TracTickets for help on using tickets.