Promise = require 'bluebird'
cb = ->
console.log 'callback!'
p = Promise.resolve(5)
.cancellable()
.tap -> p.cancel()
setInterval(cb, 100)
The cb function only is only called once. Commenting out .tap -> p.cancel() allows it to run repeatedly. Adding a try block doesn't help. Perhaps this is something obvious, but I did some research and can't find an explanation.
It would seem that the act of returning the value of p.cancel() from the tap handler is causing bluebird to go into some sort of infinite loop. You never see the second 'callback!' because the execution context is stuck in this loop before 100 ms have elapsed.
I'm still far from understanding all the factors at play here (see below), but it looks like this can be fixed by not returning p.cancel():
Promise = require 'bluebird'
cb = ->
console.log 'callback!'
p = Promise.resolve(5)
.cancellable()
.tap ->
p.cancel()
null
setInterval(cb, 100)
Edit: Ok, after looking at the source and unknotting my brain a few times, I think it boils down to this:
Execution is getting stuck in an infinite loop here, where .cancel() tries to climb up the promise chain:
while ((parent = promiseToReject._cancellationParent) !== undefined &&
parent.isCancellable()) {
promiseToReject = parent;
}
The salient points are the following:
p.cancel() returns p.
.tap() returns a promise that resolves whenever the promise returned from its handler resolves (if it returns a promise)
p is the promise that .tap() returns
In other words, p is a promise that will resolve after p resolves. It is its own ancestor in the promise chain (at least, I think so).
When .cancel() tries to climb up the promise chain to find a cancellable promise, it happens upon this incestuous relationship and starts going in circles forever.
In the end, it's an unfortunate consequence of CoffeeScript's eagerness to turn almost everything into a return statement. But I would imagine that there's some way Bluebird could detect loops in promise chains and prevent an infinite loop from happening here.
I have filed an issue for this on the bluebird GitHub repository, but as the ensuing discussion reveals, this use of .cancel() doesn't really make any sense at all anyway.
Related
The inconvenience I have is that there is no way, to my knowledge, using built-in Promise, to resolve a Promise within a synchronous block.
Specifically, the following code
var o = {};
function set(index, value) {
console.log(`setting ${index} to ${o.index = value}`);
}
Promise.resolve().then(()=>set('a', 1)).then(()=>set('b',2))
Promise.resolve().then(()=>set('c', 1)).then(()=>set('d',2))
console.log(`a is ${o.a}`);
Outputs :
a is undefined
setting a to 1
setting c to 1
setting b to 2
setting d to 2
Are there Promise like lib whose Promise would yield the following outputs:
setting a to 1
setting b to 2
setting c to 1
setting d to 2
a is 1
Obviously, no need to resort to Promises in the example above, but in my use case, setting 'a' leads to a pretreatment which only needs to be done once, whereas 'b' can be set multiple times, and is used within the same synchronous block it is set (no freedom on that).
I've looked up bluebird, and I have no clue how their promises work internally, but they seem to embrace using only promise chains.
Q Promise might be what I'm looking for, I'm not sure.
More generally, it feels daunting scouring the docs of the many Promise librairies out there querying some niche, depreciated need with likely the wrong keywords and concepts in mind.
This is definitely a case of ProblemXY where X could be solved in a variety of ways without Promises, for example by synchronous initializers, but I feel problem Y is interesting in and of itself (and likely a duplicate), so I'm still asking.
I'll get around giving problem X its own question, but long story short, I'd love to use, sometimes within a single js synchronous execution block, the expressive power of promises to pull values instead of pushing them and to flatten callbacks and try-catch pyramids.
Edit:
To clarify what I'm curious about, the way I would build the Promiselike with the desired properties is as follow :
let f = myPasync(function*(){ //equivalent to async function declaration
v = yield myPAwait(myPromiseInstance); //equivalent of v = await myPromiseInstance;
})
let pa = new myP( *(resolve, reject)=>{} ) //equivalent to new Promise((resolve, reject)=>{}) ; for simplicity, resolve and reject can be naked properties of pa
pa.myPthen((*()=>{})()) //equivalent to pa.then((v)=>{})
And then, instead of dynamically iterating over a task queue every tick, pushing thens and awaits of newly resolved promised to that queue in a FIFO manner,
I would push to the task queue in a LIFO manner and iterate over it upon any myP related function call.
So for example, when a promise is resolved, every routine awaiting it will resume before anything else, and in particular before the rest of the routine resolving the promise.
Other example when a routine awaits a promise, if that promise is already resolved, the routine is immediately resumed instead of letting other execute.
(I think I learned this, it is that .then returns a promise even if it is not run, i never knew this, thank you)
Please forgive me if this is a dumb question but I simply don't get this, I've googled this many times but those articles only talk about Promise very briefly like how to create one, how to resolve, how to .then and stuff.
I'm confused about promise chaining.
This is my code:
let p = new Promise(function (resolve, reject){
let value = 19;
if(!value){
resolve(value)
} else {
reject(value)
}
})
p.then(x => {console.log(x*x); throw false})
.then(null, x => console.log(x))
//19
This code prints 19 and I have no clue why?.
I do know every .then returns a promise but in this case, p.then shouldn't have even run because the promise is not resolved. Now in a way, it seems that didnt run but if so, why did the second .then run?
Our first .then didn't run, it didnt run any promise whatsoever, so nothing should have displayed.
Now unless 2nd .then is working the same as p.then() which I hope it doesnt because that will only create more confusions, I dont understand why will the 2nd .then run?.
I'm sorry again if my question or english bad but I'm really curious about this.
The .then function takes two functions as parameters, one which is called when the Promise resolves and one when it rejects. It returns a new Promise which gets resolved or rejected with whatever value the function which was executed returns (or throws). If no handler was executed, the Promise will just resolve or reject with the same value the Promise .then was called on.
In your example the first .then call only received one argument, and as the Promise rejects it won't be executed. Therefore the Promise it returns will also reject, and thus the second argument will be executed.
// some examples
Promise.resolve()
.then(called, notCalled);
Promise.reject()
.then(notCalled, called);
Promise.resolve(1)
.then(null, notCalled)
.then(it => it + 1, notCalled)
.then(called, notCalled);
Promise.reject(1)
.then(notCalled, null)
.then(notCalled, it => it + 1)
.then(called, notCalled);
A Promise can be in one of these states:
pending -> initial state, neither fulfilled nor rejected.
fulfilled -> the operation was completed successfully.
rejected -> the operation failed.
In your code sample, the promise is being rejected (since if value is a truthy condition).
The then method accepts two arguments:
p.then(onFulfilled[, onRejected]);
p.then(value => {
// fulfillment
}, reason => {
// rejection
});
Since the then is chainable, the reject get's fired on the second chained then which is the line of code:
x => console.log(x)
Hence, printing the value 19.
Looking at your questions on the two answers above (and also, perhaps the fact that you didn't selected either answer as correct), I wonder if you're still confused about this.
Here is an explanation based on stepping through your code:
p.then(x => {console.log(x*x); throw false})
.then(null, x => console.log(x))
Reading one token at a time:
p is a promise. It has the code as you defined for p: let p = new Promise ...
We immediately call p's then function. This runs the code in p (since p has not yet been run -- promises only run once). Your code in p is a bit confusing because it defines value to be 19, but then it says if ( !value ) ... which means "if value has no value (i.e., is falsey)". In your cause value does have a value, 19. So that causes the else part to run, which says reject(value). This moves p from an "undetermined" state to a rejected state.
Back in your main code, the then clause (the first one), only has one argument. A then clause typically has two arguments, one for code to run if the promise resolves (succeeds), and one if it fails. In your case you only provided one argument to your first then call. Since p was rejected, JavaScript doesn't run the code in the first then, but (as you point out from your learning in bold) it does still return another promise.
Now that the promise from the first then has been determined, we invoke the chained (second) then. Jonas Wilms points out the key fact: If no handler was executed, the Promise will just resolve or reject with the same value the Promise .then was called on. So that means the second then gets the same result as the first then, rejected.
Since the second then has two arguments, JavaScript runs the second one (the one for the rejection case), which prints 19.
I'm a little confused about how the sequencing works in various documents I've come across. For instance, I have seen this sort of thing
let p = Promise.resolve();
for (let x in something)
{
/* do some hairy time consuming code */
p = p.then(dosomething(x));
}
return p.then(finalthing()).catch(pretendnobadthing());
What I really don't understand is that if you do something that takes a large amount of time in the main code, wouldn't that mean that one of the promises could complete before the main code actually got round to to setting up the .then.
Can you always use .then/.catch on a promise, and if its already reached completion, it'll carry on from the point it got to, so it conceptually looks like a big chain that will run to completion at some indeterminate point? And if so, doesn't that mean every time you create a promise chain it'll hang about for ever?
Can you always use .then/.catch on a promise, and if its already reached completion, it'll carry on from the point it got to, so it conceptually looks like a big chain that will run to completion at some indeterminate point?
Yes, you can always use .then/.catch on a promise. When you call p.then(), there are three possibilities.
The promise p is still pending (not fulfilled or rejected yet). If that's the case, then the function reference(s) you passed to .then() are registered as listeners for that promise. So, when a future state transition happens on the promise (either going from pending => fulfilled or from pending => rejected), then the appropriate registered listeners will be called.
The promise p is already fulfilled. If that's the case, then calling .then(f1, f2) will schedule f1 to be called on the next tick (after the current piece of Javascript finishes executing) and it will be passed the saved resolved value.
The promise p is already rejected. If that's the case, then calling .then(f1, f2) will schedule f2 to be called on the next tick (after the current piece of Javascript finishes executing) and it will be passed the saved reject reason.
So, it's perfectly safe to call .then() on a promise that is already fulfilled or rejected. The appropriate listener will just be scheduled to run on the next tick.
The same logic applies to .catch() except it is only interested in cases 1 and 3 above.
Here are
And if so, doesn't that mean every time you create a promise chain it'll hang about for ever?
Promises are just objects like any other objects in Javascript. They will hang around only while other code still has some live reference to them. As soon as there is no longer any way to reach that promise object, they will be eligible for garbage collection just like any other objects in Javascript.
So, if you do:
var p = somePromiseReturningFunction();
p.then(f1).then(f2).then(f3);
Then, p will remain around until somePromiseReturningFunction() is done with any references to the promise that it returned (usually, though not always, this occurs when the promise is finally fulfilled or rejected) and when the variable p goes out of scope. If p never goes out of scope (like when it's global or in some other lasting scope), then it will remain forever (just like any other Javascript object).
There are some misconceptions in your question so let me attempt to square those up.
You're using the construct p = p.then(dosomething(x)); which is likely not correct. You need to pass .then() a function reference. So, unless you want doSomething(x) to execute immediately and it also returns another function that is what you want called as then .then() handler (which seems unlikely here), then this is not the right construct. You probably meant to have:
p = p.then(result => dosomething(x));
or in ES5 syntax:
p = p.then(function(result) {
return dosomething(x)
});
You show the same issue in this too:
return p.then(finalthing()).catch(pretendnobadthing());
which should probably be:
return p.then(finalthing).catch(pretendnobadthing);
Remember, when you use f(), that means to execute f immediately. When you just pass f, that passes a function reference which the underlying function/method you are passing it to can then call later at the time of its choosing which is what you want for .then() and .catch() handlers.
What I really don't understand is that if you do something that takes a large amount of time in the main code, wouldn't that mean that one of the promises could complete before the main code actually got round to to setting up the .then.
First off, my original explanation at the beginning of my answer should explain that calling .then() on an already resolved promise is perfectly fine so this isn't an issue at all. It will just schedule action on the next tick of the event loop.
But, that isn't even the case here because Javascript in the browser and node.js is single-threaded so while your long-running code is running, that promise (who's async action was previously started) can't yet get resolved. Though the underlying async operation may be done and an event may be sitting in the Javascript event queue that will trigger a callback that will resolve the promise, that event in the event queue won't get processed until the current piece of Javascript that is executing is done and returns control to the system.
What I really don't understand is that if you do something that takes a large amount of time in the main code, wouldn't that mean that one of the promises could complete before the main code actually got round to to setting up the .then.
Since common implementations of JavaScript never run it in parallel, no. Nevertheless,
Can you always use .then/.catch on a promise, and if its already reached completion, it'll carry on from the point it got to, so it conceptually looks like a big chain that will run to completion at some indeterminate point?
yes! This is a big advantage of promises. Take this for example:
var promise = Promise.resolve(5); // already resolved here
setTimeout(function () {
promise.then(function (x) {
console.log(x); // still logs 5
});
}, 1000);
And if so, doesn't that mean every time you create a promise chain it'll hang about for ever?
Until it’s resolved, yes, but if the promise has already been resolved and there are no ways to reference it anymore, it can be disposed of like any other object.
I have a use case where the user makes a selection. I initiate a promise. With the most basic case, the user makes a second selection and the promise gets resolved.
In a more complex use case, the user makes a second selection that results in having to 'start over'. So what I want to happen is that the outstanding promise is 'cancelled' and a new promise is initiated.
I am new to promises and am working with the bluebird library. I played around with .cancel() but that did not seem to work as required. From what I could tell the promise still existed. Future iteration then started tripping over each other.
What did work is creating the promise as such:
var el = Promise.resolve( id );
and then when canceling simply:
el = {};
As I noted, everything seems to work fine. My question is this, is setting a promise to an empty object causing any harm? Am I leaving code out there that will never resolve? Am I missing something basic?
If I create a single Deferred object, then it reports progress like I would expect.
var d1 = function() {
var d = $.Deferred();
d.notify('d1');
d.resolve('d1');
return d.promise();
};
d1().progress(function(a) {
log('Progress: ' + a);
});
However, if I chain two Deferred objects using then(), the progress callbacks are not called.
d1().then(d1).progress(function(a) {
log('Progress: ' + a);
});
It seems to me that then() should propagate the progress notification, but it doesn't appear to be the case. Am I missing something?
I have tested this with jQuery 1.8.0 and 1.8.1. A full working example is here: http://jsfiddle.net/eWQuG/13/
I can see what's going on but it's slightly tricky to explain. You may have to read this through a couple of times ...
In Test 1, the promise passed to test() is the "original promise" ie. the object returned by d1(). Simple.
In Test 2, the object passed to test() is a new promise resulting from d1().then(d2).then(d3). Less simple. This new promise will have inherited only some of the original promise's properties - not including its progressCallbacks (as put in place in the original promise with notify()). This is reasonable for a promise returned by .then(), because .then() is designed to put in place its own doneCallbacks, failCallbacks and progressCallbacks, not to propagate those of the deferred/promise to its immediate left. In short, .then() does exactly what its name implies - it specifies what is to be done after its preceding deferred/promise has been processed.
You can better see what's going on by keeping a reference to the original promise (ie. the output of d1()), thus allowing the simple Test 1 to be run both before and after Test 2.
Here is a composite Test 3 :
log('-- Test 3 --');
var p = d1();//p is a promise
test(p);//equivalent to Test 1
test(p.then(d2).then(d3));//equivalent to Test 2
test(p);//equivalent to Test 1 again
DEMO
In the log, you will see that the behaviour of test(p) is identical in both cases. However, test(p.then(d2).then(d3)) behaves differently because the object passed is no longer the original promise but a new promise with no progressCallbacks.
EDIT
Ryan, something maybe worth considering in achieving what you want with :
d1().then(d2).progress(function(a) {
log('Progress: ' + a);
});
is that a the chain can be rearranged as follows :
d1().progress(function(a) {
log('Progress: ' + a);
}).then(d2);
The progress callback is thus applied to the original promise and because .progress() propagates the original promise down the chain, .then() will still act as before.
Both versions are valid but would be applicable in different circumstances.
If I'm right then maybe this is the short answer to your question.
You are doing a few weird things in your tests that are not really logical.
One, you are resolving the promise before you even return it, which defeat the purpose of promises. Promise callbacks are not supposed to be called on previously resolved promises, simple as that.
var p = $.Deferred();
p.then(function(p){log("ok")}).progress(function(p){log("progress " + p)});
p.notify('n1'); // will call handler and be logged
p.resolve();
p.notify('n2'); // will not call handler and will not be logged
Two, you are calling "notify" before you have set the progress callback, but that is somehow still working properly to a degree - it seems jQuery's particular implementation of notify is somewhat async... Except it fails with chaining. How or why, I don't know, but I don't think it is important to debug as your usage is improper anyway.
See this update to your fiddle:
http://jsfiddle.net/eWQuG/15/