-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crazy progress use cases #6
Comments
I've ported the fast/slow case with the following results:
Which makes sense to me. |
Would be nice to see the resulting code for each case as well? |
Sorry, yes. Edited. |
Off the top of my head:
|
More:
|
This covers the scenario where the promise for the propagation value only fulfills after the original promise is fulfilled. Since progress can't be emitted once the promise is no longer pending, I think it should also hold that progress can't propagate once the promise the propagation originates from is no longer pending. Legendary already behaved this way, but it should be clarified in the spec. A more complicated propagation scenario is when a fast promise is chained with a slow one: var A = pending();
var B = pending();
var C = pending();
var spy = sinon.spy();
var p = A.promise.then(function(){
return B.promise;
});
var q = p.then(null, null, function(){
return C.promise;
});
q.then(null, null, spy);
A.progress();
A.fulfill();
C.fulfill();
// later
assert(!spy.called); The spy shouldn't be called, since progress is propagated after A has been fulfilled, however propagation can't be prevented without canceling promises. When This would mean that support of Cancelation is required to implement Progress.
Assuming you mean "fast" and "slow" in respect to when they fulfill, their behavior is covered by the previous cases. Unless you mean a promise that emits progress quickly and slowly? The way it's specified right now, only the fulfillment value of a promise returned from a progress handler is used as the propagation value. Any progress emitted by that returned promise is ignored. |
#5 is concluding with an updated draft (https://gist.github.com/4400252) and an implementation. We now need a list of progress use cases and see if the behavior that flows from the spec is as expected.
The text was updated successfully, but these errors were encountered: