Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#14916 closed bug (notabug)

The nested promise handlers are queued

Reported by: zerkms@… 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

Change History (4)

comment:1 Changed 6 years ago by dmethvin

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.

comment:2 Changed 6 years ago by zerkms@…

@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

comment:3 Changed 6 years ago by dmethvin

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.

comment:4 Changed 6 years ago by zerkms@…

@dmethvin,

alright, thanks.

Note: See TracTickets for help on using tickets.