Skip to main content

Bug Tracker

Side navigation

#10467 closed feature (wontfix)

Opened October 10, 2011 07:16PM UTC

Closed December 09, 2012 05:29PM UTC

Deferreds should always resolve asynchronously

Reported by: scottgonzalez Owned by:
Priority: low Milestone: 1.9
Component: deferred Version: 1.6.4
Keywords: 1.8-discuss Cc:
Blocked by: Blocking:
Description

Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous.

This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.

Attachments (0)
Change History (18)

Changed October 10, 2011 07:26PM UTC by scottgonzalez comment:1

component: unfileddeferred
summary: Deferreds should should always resolve asynchronouslyDeferreds should always resolve asynchronously

Changed October 10, 2011 09:29PM UTC by jaubourg comment:2

I agree, but async=false in $.ajax() disagrees.

If we want to make Deferred 100% asynchronous, then we have to remove synchronous ajax requests (which I'd love to be able to do btw, but I doubt I'll see the day).

Changed October 11, 2011 12:16PM UTC by scottgonzalez comment:3

Do we know if there's a lot of use of deferreds on sync XHR requests?

If we can't always force deferreds to resolve asynchronously, can we at least have an option during creation of the deferred for whether or not it should be forced to be async, with the default being async? Then sync XHR can set the flag and continue working as it does today.

Changed October 12, 2011 02:04PM UTC by dmethvin comment:4

status: newopen

Changed October 17, 2011 10:49PM UTC by jaubourg comment:5

OK, so this is clearly about changing behaviour... do I wait for 1.8 for trying and fixing it or do I try it for 1.7? (async option was something I intended to add in $.Callbacks later on FYI)

Changed December 13, 2011 04:51PM UTC by jaubourg comment:6

blockedby: → 11013
keywords: → 1.8-discuss
milestone: None1.8
priority: undecidedlow

Changed December 13, 2011 04:57PM UTC by jaubourg comment:7

description: Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous. \ \ This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous.\ \ This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.

+1

Changed December 14, 2011 01:15PM UTC by mikesherov comment:8

+0

Changed December 14, 2011 04:08PM UTC by timmywil comment:9

+0, As I understand it, we are sometimes dependent on the synchronous nature of certain deferreds.

Changed December 19, 2011 05:33PM UTC by rwaldron comment:10

description: Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous.\ \ This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous. \ \ This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.

+1

Changed May 14, 2012 05:01PM UTC by gnarf comment:11

I'm against this at this point, I can't use Deferred in animate any longer if it becomes async. No matter what we end up doing, It would break at least two use cases within jQuery core to not somehow still support the sync behavior.

Changed June 04, 2012 05:13PM UTC by gnarf comment:12

I retract my earlier complaint under the assumption that this only causes a "async" step if it is resolved/rejected in the same event loop it was created in.

Changed June 04, 2012 05:20PM UTC by scottgonzalez comment:13

@gnarf That is my intention. If the deferred is resolved in a future tick then the callbacks should be invoked in that same tick (synchronous with the resolution, but asynchronous compared to the creation of the deferred).

Changed June 04, 2012 06:02PM UTC by dmethvin comment:14

milestone: 1.81.9

Pushing to 1.9, current plan is to move the now-deprecated async:false option to a compat plugin which would allow $.Deferred to be totally async.

Changed July 09, 2012 02:57PM UTC by tj@crowdersoftware.com comment:15

+1, if a callback may occur asynchronously to the code hooking it up, it should always occur asynchronously to that code. In fact, I recently file ticket #12044 because ready is chaotic in this respect.

Changed September 09, 2012 01:10AM UTC by dmethvin comment:16

type: enhancementfeature

Bulk change from enhancement to feature.

Changed December 03, 2012 06:07PM UTC by jaubourg comment:17

blocking: → 12044

Changed December 09, 2012 05:29PM UTC by dmethvin comment:18

resolution: → wontfix
status: openclosed

In the email thread we had, it seemed like there was just too much potential for breaking lots of code (including cases currently in our own ajax and effects) so I don't think we can do this. Note that the Promise/A discussion leaves this intentionally unspecified.