Skip to content

Conversation

@timmywil
Copy link
Member

Fixes gh-2546
Fixes gh-2018

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a behavior difference. For $.when( 1 ), window is the context instead of undefined, but this is closer to $.when( 1, 1 ), which has historically resolved with a context of [ window, window ].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not since at least jQuery 1.8.3: http://jsfiddle.net/av4shtg8/ . I complained about the cast/all mixing in #2018, but lost.

This test code should not be altered, and the behavior change should be reverted. If anything, the problem is that the Callbacks apply converts our undefined context into the global object, but there's nothing we can do about that language-level operation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But, why? What's the point of returning undefined instead of window, or vice versa? I imagine neither is being used very often. And why are we continuing to do different things for $.when( 1 ) and $.when( 1, 1 )? jQuery 1.8.3 looks just as bad, only swapped. Time to get them to do the same thing.

I can't revert this change without doing ugly things or dumping this PR and closing #2018 wontfix. The point is to make single arguments and multiple arguments do the same thing. We can either do that or we can't. I don't really care if we do undefined or window, but let's choose one or the other for all cases, not a mixture.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either context seems sufficiently useless that it does seem unlikely anyone is using them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to leave it. Returning window and [ window, window ] seems better than undefined and [ window, window ]. However, I agree that getting window out of passing undefined is an odd language quirk, but I think all the windows will be undefineds in global strict mode.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to leave it. Returning window and [ window, window ] seems better than undefined and [ window, window ]

Meh.

I think all the windows will be undefineds in global strict mode.

Correct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why are we continuing to do different things for $.when( 1 ) and $.when( 1, 1 )… Time to get them to do the same thing.`

Look, I made the same argument, but lost. And the differences go beyond context—jQuery.when( value ) and jQuery.when( value1, …, valueN ) are actually different operations, with different signatures.

@timmywil timmywil force-pushed the when-2546 branch 2 times, most recently from 334b9ea to 246d263 Compare November 11, 2015 16:20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you did there!

@dmethvin
Copy link
Member

This logic could be simplified a lot further if we got rid of the special case handling for Deferred and just used the thenables path. It would mean we'd lose progress notification on Deferreds but I'm not even sure how aggregated and interspersed progress info from several Deferreds would be used effectively by a caller. In any case the behavior of progress notifications with jQuery.when is not documented.

@timmywil
Copy link
Member Author

I'm not even sure how aggregated and interspersed progress info from several Deferreds would be used effectively by a caller.

Perhaps a user could have a progress bar for each request along with a progress bar for all of them?

@timmywil
Copy link
Member Author

While I'm not opposed to doing this, isn't removing progress handling from $.when a separate issue? I didn't see any responses to your comment about removing progress. I'm wondering if we have consensus.

@dmethvin
Copy link
Member

We can make it a separate thing and land this PR first. It seems that $.when progress is broken for a common use case anyway, the natural thing you might want from progress on the master is whether the other promises have resolved. http://stackoverflow.com/questions/26066198/jquery-when-progress-for-array-of-deferred-and-or-promise

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

var done = assert.async(). We don't need QUnit.stop anymore. 😺

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I started with that. I went with QUnit.stop given how prevalent it is in our code, but I'll switch it back.

@gibson042
Copy link
Member

Where are the tests for #2018?

@timmywil
Copy link
Member Author

I didn't realize there are tests needed for #2018. Is there a behavior difference that I'm not accounting for? It seemed like just a refactor that would be covered by existing tests.

@mgol
Copy link
Member

mgol commented Nov 12, 2015

Is there a behavior difference that I'm not accounting for?

You're returning a new Deferred instead of reusing the old one; that's a behavior change; the new bahavior is one that many promise libs are careful about. This definitely needs to be tested.

@timmywil
Copy link
Member Author

@gibson042 Now that I think about it, I could add tests that explicitly address the fact that we're not returning the original Deferred anymore. Is that what you mean?

@timmywil
Copy link
Member Author

You're returning a new Deferred instead of reusing the old one.

Yup, silly me.

@timmywil timmywil changed the title Deferred: syncronize single and multiple target handling in $.when Deferred: synchronize single and multiple target handling in $.when Nov 12, 2015
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

notEqualnotStrictEqual

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@timmywil
Copy link
Member Author

To sum up for the log, this PR led to opening two more issues for Deferred. #2709, which we probably won't get to before 3.0, and #2710, which we will. The concerns about progress + when are not addressed here, but we will address them before 3.0 is released.

@timmywil timmywil merged commit 78b9eac into jquery:master Nov 13, 2015
@timmywil timmywil deleted the when-2546 branch November 13, 2015 16:18
@lock lock bot locked as resolved and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

jQuery.when doesn't recognize solitary thenables Remove single-promiseable exception in jQuery.when

5 participants