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 comment:1
| component: | unfiled → deferred |
|---|---|
| summary: | Deferreds should should always resolve asynchronously → Deferreds should always resolve asynchronously |
Changed October 10, 2011 09:29PM UTC by 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 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 comment:4
| status: | new → open |
|---|
Changed October 17, 2011 10:49PM UTC by 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 comment:6
| blockedby: | → 11013 |
|---|---|
| keywords: | → 1.8-discuss |
| milestone: | None → 1.8 |
| priority: | undecided → low |
Changed December 13, 2011 04:57PM UTC by 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 comment:8
+0
Changed December 14, 2011 04:08PM UTC by 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 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 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 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 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 comment:14
| milestone: | 1.8 → 1.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 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 comment:16
| type: | enhancement → feature |
|---|
Bulk change from enhancement to feature.
Changed December 03, 2012 06:07PM UTC by comment:17
| blocking: | → 12044 |
|---|
Changed December 09, 2012 05:29PM UTC by comment:18
| resolution: | → wontfix |
|---|---|
| status: | open → closed |
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.