Skip to main content

Bug Tracker

Side navigation

#14916 closed bug (notabug)

Opened March 26, 2014 02:10AM UTC

Closed March 26, 2014 02:48AM UTC

Last modified March 26, 2014 03:37AM UTC

The nested promise handlers are queued

Reported by: zerkms@zerkms.ru Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.11.0
Keywords: Cc:
Blocked by: Blocking:
Description

It's either a documentation or implementation bug (I'd prefer if it was the latter though :-D)

The http://api.jquery.com/jQuery.Deferred/ page states: "Once the object has entered the resolved or rejected state, it stays in that state. Callbacks can still be added to the resolved or rejected Deferred — they will execute immediately."

Whereas for the given code:

var d = $.Deferred();

var a = function() {
    d.done(function() {
        console.log('inner');
    });

    console.log('outer');
};

d.resolve();

d.done(a);

The inner will be output **after** outer.

Personally I think that the d.done(a); behaviour in this case should be exactly the same to the simple a() call, whereas it's not the case.

PS: a tiny stackoverflow discussion on that: http://stackoverflow.com/q/22649505/251311

Attachments (0)
Change History (4)

Changed March 26, 2014 02:48AM UTC by dmethvin comment:1

resolution: → notabug
status: newclosed

The SO answer does a good job of explaining this, and I agree with that answer--it's a pretty esoteric case. Adding a bunch of additional words to the docs explaining this would probably make it harder to understand for the most common cases. You're welcome to make a pull request at https://github.com/jquery/api.jquery.com/ if you think you can clarify in a simple way.

Changed March 26, 2014 03:14AM UTC by zerkms@zerkms.ru comment:2

@dmethvin,

does it mean the current implementation behaves as intended?

Was such a case kept in mind when promises were designed?

If not - is the current behaviour correct?

The SO answer only explains the current implementation (which is actually obvious), not the original intentions. And my question was more about correctness of behaviour

Changed March 26, 2014 03:34AM UTC by dmethvin comment:3

does it mean the current implementation behaves as intended?

Yes, and it can't be changed without risking compat issues.

Was such a case kept in mind when promises were designed?

You'd need to go back to 2010 to answer that, I don't know. I think it's a pretty crazy case but understand that it may have been distilled down from something more complex.

If not - is the current behaviour correct?

It is working as intended, I don't think it contradicts the docs. We don't follow Promise/A+ which came out after Deferred, if you want those semantics just include a Promise library or polyfill.

Changed March 26, 2014 03:37AM UTC by zerkms@zerkms.ru comment:4

@dmethvin,

alright, thanks.