When is the body of a Promise executed?
up vote
25
down vote
favorite
Suppose I have the following Promise
:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
const result = doSomeWork();
setTimeout(() => {
resolve(result);
}), 100);
});
}
At which point in time is doSomeWork()
called? Is it immediately after or as the Promise
is constructed? If not, is there something additional I need to do explicitly to make sure the body of the Promise
is run?
javascript ecmascript-6 promise es6-promise
|
show 3 more comments
up vote
25
down vote
favorite
Suppose I have the following Promise
:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
const result = doSomeWork();
setTimeout(() => {
resolve(result);
}), 100);
});
}
At which point in time is doSomeWork()
called? Is it immediately after or as the Promise
is constructed? If not, is there something additional I need to do explicitly to make sure the body of the Promise
is run?
javascript ecmascript-6 promise es6-promise
2
ECMAScript, 25.4.3.1Promise(executor)
-> Step 9
– Andreas
Feb 8 '17 at 16:49
It doesn't matter: if you need to enforce order of operations, do so explicitly. Different implementations will handle promises with slight differences in behavior (bluebird vs native map, for example).
– ssube
Feb 8 '17 at 16:52
@guest271314 I'm writing some tests and need to mock a function that returns a Promise. I want the Promises the mock returns to resolve immediately so that the tests run successfully, so I just wanted to double-check that there wasn't some kind of magic I had to invoke to get them to run.
– Kevin
Feb 8 '17 at 17:21
That, and I want to understand how Promises work under the hood.
– Kevin
Feb 8 '17 at 17:21
2
This may help explain things: stackoverflow.com/questions/42031051/…. It covers a slightly more complicated situation (a promise within a promise), but definitely covers what is going on here, including what happens when a promise resolves before the.then()
handlers are attached.
– jfriend00
Feb 8 '17 at 17:41
|
show 3 more comments
up vote
25
down vote
favorite
up vote
25
down vote
favorite
Suppose I have the following Promise
:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
const result = doSomeWork();
setTimeout(() => {
resolve(result);
}), 100);
});
}
At which point in time is doSomeWork()
called? Is it immediately after or as the Promise
is constructed? If not, is there something additional I need to do explicitly to make sure the body of the Promise
is run?
javascript ecmascript-6 promise es6-promise
Suppose I have the following Promise
:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
const result = doSomeWork();
setTimeout(() => {
resolve(result);
}), 100);
});
}
At which point in time is doSomeWork()
called? Is it immediately after or as the Promise
is constructed? If not, is there something additional I need to do explicitly to make sure the body of the Promise
is run?
javascript ecmascript-6 promise es6-promise
javascript ecmascript-6 promise es6-promise
edited Sep 26 '17 at 21:01
asked Feb 8 '17 at 16:45
Kevin
4,904104690
4,904104690
2
ECMAScript, 25.4.3.1Promise(executor)
-> Step 9
– Andreas
Feb 8 '17 at 16:49
It doesn't matter: if you need to enforce order of operations, do so explicitly. Different implementations will handle promises with slight differences in behavior (bluebird vs native map, for example).
– ssube
Feb 8 '17 at 16:52
@guest271314 I'm writing some tests and need to mock a function that returns a Promise. I want the Promises the mock returns to resolve immediately so that the tests run successfully, so I just wanted to double-check that there wasn't some kind of magic I had to invoke to get them to run.
– Kevin
Feb 8 '17 at 17:21
That, and I want to understand how Promises work under the hood.
– Kevin
Feb 8 '17 at 17:21
2
This may help explain things: stackoverflow.com/questions/42031051/…. It covers a slightly more complicated situation (a promise within a promise), but definitely covers what is going on here, including what happens when a promise resolves before the.then()
handlers are attached.
– jfriend00
Feb 8 '17 at 17:41
|
show 3 more comments
2
ECMAScript, 25.4.3.1Promise(executor)
-> Step 9
– Andreas
Feb 8 '17 at 16:49
It doesn't matter: if you need to enforce order of operations, do so explicitly. Different implementations will handle promises with slight differences in behavior (bluebird vs native map, for example).
– ssube
Feb 8 '17 at 16:52
@guest271314 I'm writing some tests and need to mock a function that returns a Promise. I want the Promises the mock returns to resolve immediately so that the tests run successfully, so I just wanted to double-check that there wasn't some kind of magic I had to invoke to get them to run.
– Kevin
Feb 8 '17 at 17:21
That, and I want to understand how Promises work under the hood.
– Kevin
Feb 8 '17 at 17:21
2
This may help explain things: stackoverflow.com/questions/42031051/…. It covers a slightly more complicated situation (a promise within a promise), but definitely covers what is going on here, including what happens when a promise resolves before the.then()
handlers are attached.
– jfriend00
Feb 8 '17 at 17:41
2
2
ECMAScript, 25.4.3.1
Promise(executor)
-> Step 9– Andreas
Feb 8 '17 at 16:49
ECMAScript, 25.4.3.1
Promise(executor)
-> Step 9– Andreas
Feb 8 '17 at 16:49
It doesn't matter: if you need to enforce order of operations, do so explicitly. Different implementations will handle promises with slight differences in behavior (bluebird vs native map, for example).
– ssube
Feb 8 '17 at 16:52
It doesn't matter: if you need to enforce order of operations, do so explicitly. Different implementations will handle promises with slight differences in behavior (bluebird vs native map, for example).
– ssube
Feb 8 '17 at 16:52
@guest271314 I'm writing some tests and need to mock a function that returns a Promise. I want the Promises the mock returns to resolve immediately so that the tests run successfully, so I just wanted to double-check that there wasn't some kind of magic I had to invoke to get them to run.
– Kevin
Feb 8 '17 at 17:21
@guest271314 I'm writing some tests and need to mock a function that returns a Promise. I want the Promises the mock returns to resolve immediately so that the tests run successfully, so I just wanted to double-check that there wasn't some kind of magic I had to invoke to get them to run.
– Kevin
Feb 8 '17 at 17:21
That, and I want to understand how Promises work under the hood.
– Kevin
Feb 8 '17 at 17:21
That, and I want to understand how Promises work under the hood.
– Kevin
Feb 8 '17 at 17:21
2
2
This may help explain things: stackoverflow.com/questions/42031051/…. It covers a slightly more complicated situation (a promise within a promise), but definitely covers what is going on here, including what happens when a promise resolves before the
.then()
handlers are attached.– jfriend00
Feb 8 '17 at 17:41
This may help explain things: stackoverflow.com/questions/42031051/…. It covers a slightly more complicated situation (a promise within a promise), but definitely covers what is going on here, including what happens when a promise resolves before the
.then()
handlers are attached.– jfriend00
Feb 8 '17 at 17:41
|
show 3 more comments
4 Answers
4
active
oldest
votes
up vote
29
down vote
accepted
Immediately, yes, by specification.
From the MDN:
The executor function is executed immediately by the Promise implementation, passing resolve and reject functions (the executor is called before the Promise constructor even returns the created object)
Here it is in the ECMAScript specification (of course harder to read...): http://www.ecma-international.org/ecma-262/6.0/#sec-promise-executor
This guarantee may be important, for example when you're preparing several promises you then pass to all
or race
, or when your executors have synchronous side effects.
6
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
add a comment |
up vote
4
down vote
Yes, when you construct a Promise the first parameter gets executed immediately.
In general, you wouldn't really use a promise in the way you did, as with your current implementation, it would still be synchronous.
You would rather implement it with a timeout, or call the resolve function as part of an ajax callback
function doSomethingAsynchronous() {
return new Promise((resolve) => {
setTimeout(function() {
const result = doSomeWork();
resolve(result);
}, 0);
});
}
The setTimeout method would then call the function at the next possible moment the event queue is free
add a comment |
up vote
0
down vote
You can see from below the body is executed immediately just by putting synchronous code in the body rather than asynchronous:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
console.log("a");
resolve("promise result");
});
}
doSomethingAsynchronous();console.log("b");
The result shows the promise body is executed immediately (before 'b' is printed):
a
b
The result of the Promise is retained, to be released to a 'then' call for example:
doSomethingAsynchronous().then(function(pr){console.log("c:"+pr);});console.log("b");
Result:
a
b
c:promise result
Same deal with asynchronous code in the body except the indeterminate delay before the promise is fulfilled and 'then' can be called (point 'c'). So 'a' and 'b' would be printed as soon as doSomethingAsynchronous()
returns but 'c' appears only when the promise is fulfilled ('resolve' is called).
What looks odd on the surface, once the call to 'then' is added, is that 'b' is printed before 'c' even when everything is synchronous. Surely 'a' would print, then 'c' and finally 'b'? The reason why 'a', 'b' and 'c' are printed in that order is because no matter whether code in the body is async or sync, the 'then' method is always called asynchronously by the Promise. In my mind, I imagine the 'then' method being invoked by something like setTimeout(function(){then(pr);},0);
in the Promise once 'resolve' is called. I.e. the current execution path must complete before the function passed to 'then' will be executed. Not obvious from the Promise specification why it does this. My guess is it ensures consistent behaviour regarding when 'then' is called (always after current execution thread finishes) which is presumably to allow multiple Promises to be stacked/chained together before kicking off all the 'then' calls in succession.
add a comment |
up vote
-1
down vote
Yes, since the call is synchronous it will be called immediately, before attaching any ".then"s or ".catch"s.
The promise will already be resolved by the time the first ".then" is attached and it will immediately pass down the resolve value.
1
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
29
down vote
accepted
Immediately, yes, by specification.
From the MDN:
The executor function is executed immediately by the Promise implementation, passing resolve and reject functions (the executor is called before the Promise constructor even returns the created object)
Here it is in the ECMAScript specification (of course harder to read...): http://www.ecma-international.org/ecma-262/6.0/#sec-promise-executor
This guarantee may be important, for example when you're preparing several promises you then pass to all
or race
, or when your executors have synchronous side effects.
6
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
add a comment |
up vote
29
down vote
accepted
Immediately, yes, by specification.
From the MDN:
The executor function is executed immediately by the Promise implementation, passing resolve and reject functions (the executor is called before the Promise constructor even returns the created object)
Here it is in the ECMAScript specification (of course harder to read...): http://www.ecma-international.org/ecma-262/6.0/#sec-promise-executor
This guarantee may be important, for example when you're preparing several promises you then pass to all
or race
, or when your executors have synchronous side effects.
6
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
add a comment |
up vote
29
down vote
accepted
up vote
29
down vote
accepted
Immediately, yes, by specification.
From the MDN:
The executor function is executed immediately by the Promise implementation, passing resolve and reject functions (the executor is called before the Promise constructor even returns the created object)
Here it is in the ECMAScript specification (of course harder to read...): http://www.ecma-international.org/ecma-262/6.0/#sec-promise-executor
This guarantee may be important, for example when you're preparing several promises you then pass to all
or race
, or when your executors have synchronous side effects.
Immediately, yes, by specification.
From the MDN:
The executor function is executed immediately by the Promise implementation, passing resolve and reject functions (the executor is called before the Promise constructor even returns the created object)
Here it is in the ECMAScript specification (of course harder to read...): http://www.ecma-international.org/ecma-262/6.0/#sec-promise-executor
This guarantee may be important, for example when you're preparing several promises you then pass to all
or race
, or when your executors have synchronous side effects.
edited Feb 8 '17 at 17:12
answered Feb 8 '17 at 16:48
Denys Séguret
272k51573589
272k51573589
6
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
add a comment |
6
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
6
6
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
Immediately is confusing. The executor is really called synchronously by the Promise constructor.
– Paleo
Sep 28 '17 at 15:11
add a comment |
up vote
4
down vote
Yes, when you construct a Promise the first parameter gets executed immediately.
In general, you wouldn't really use a promise in the way you did, as with your current implementation, it would still be synchronous.
You would rather implement it with a timeout, or call the resolve function as part of an ajax callback
function doSomethingAsynchronous() {
return new Promise((resolve) => {
setTimeout(function() {
const result = doSomeWork();
resolve(result);
}, 0);
});
}
The setTimeout method would then call the function at the next possible moment the event queue is free
add a comment |
up vote
4
down vote
Yes, when you construct a Promise the first parameter gets executed immediately.
In general, you wouldn't really use a promise in the way you did, as with your current implementation, it would still be synchronous.
You would rather implement it with a timeout, or call the resolve function as part of an ajax callback
function doSomethingAsynchronous() {
return new Promise((resolve) => {
setTimeout(function() {
const result = doSomeWork();
resolve(result);
}, 0);
});
}
The setTimeout method would then call the function at the next possible moment the event queue is free
add a comment |
up vote
4
down vote
up vote
4
down vote
Yes, when you construct a Promise the first parameter gets executed immediately.
In general, you wouldn't really use a promise in the way you did, as with your current implementation, it would still be synchronous.
You would rather implement it with a timeout, or call the resolve function as part of an ajax callback
function doSomethingAsynchronous() {
return new Promise((resolve) => {
setTimeout(function() {
const result = doSomeWork();
resolve(result);
}, 0);
});
}
The setTimeout method would then call the function at the next possible moment the event queue is free
Yes, when you construct a Promise the first parameter gets executed immediately.
In general, you wouldn't really use a promise in the way you did, as with your current implementation, it would still be synchronous.
You would rather implement it with a timeout, or call the resolve function as part of an ajax callback
function doSomethingAsynchronous() {
return new Promise((resolve) => {
setTimeout(function() {
const result = doSomeWork();
resolve(result);
}, 0);
});
}
The setTimeout method would then call the function at the next possible moment the event queue is free
answered Feb 8 '17 at 16:49
Icepickle
8,43232034
8,43232034
add a comment |
add a comment |
up vote
0
down vote
You can see from below the body is executed immediately just by putting synchronous code in the body rather than asynchronous:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
console.log("a");
resolve("promise result");
});
}
doSomethingAsynchronous();console.log("b");
The result shows the promise body is executed immediately (before 'b' is printed):
a
b
The result of the Promise is retained, to be released to a 'then' call for example:
doSomethingAsynchronous().then(function(pr){console.log("c:"+pr);});console.log("b");
Result:
a
b
c:promise result
Same deal with asynchronous code in the body except the indeterminate delay before the promise is fulfilled and 'then' can be called (point 'c'). So 'a' and 'b' would be printed as soon as doSomethingAsynchronous()
returns but 'c' appears only when the promise is fulfilled ('resolve' is called).
What looks odd on the surface, once the call to 'then' is added, is that 'b' is printed before 'c' even when everything is synchronous. Surely 'a' would print, then 'c' and finally 'b'? The reason why 'a', 'b' and 'c' are printed in that order is because no matter whether code in the body is async or sync, the 'then' method is always called asynchronously by the Promise. In my mind, I imagine the 'then' method being invoked by something like setTimeout(function(){then(pr);},0);
in the Promise once 'resolve' is called. I.e. the current execution path must complete before the function passed to 'then' will be executed. Not obvious from the Promise specification why it does this. My guess is it ensures consistent behaviour regarding when 'then' is called (always after current execution thread finishes) which is presumably to allow multiple Promises to be stacked/chained together before kicking off all the 'then' calls in succession.
add a comment |
up vote
0
down vote
You can see from below the body is executed immediately just by putting synchronous code in the body rather than asynchronous:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
console.log("a");
resolve("promise result");
});
}
doSomethingAsynchronous();console.log("b");
The result shows the promise body is executed immediately (before 'b' is printed):
a
b
The result of the Promise is retained, to be released to a 'then' call for example:
doSomethingAsynchronous().then(function(pr){console.log("c:"+pr);});console.log("b");
Result:
a
b
c:promise result
Same deal with asynchronous code in the body except the indeterminate delay before the promise is fulfilled and 'then' can be called (point 'c'). So 'a' and 'b' would be printed as soon as doSomethingAsynchronous()
returns but 'c' appears only when the promise is fulfilled ('resolve' is called).
What looks odd on the surface, once the call to 'then' is added, is that 'b' is printed before 'c' even when everything is synchronous. Surely 'a' would print, then 'c' and finally 'b'? The reason why 'a', 'b' and 'c' are printed in that order is because no matter whether code in the body is async or sync, the 'then' method is always called asynchronously by the Promise. In my mind, I imagine the 'then' method being invoked by something like setTimeout(function(){then(pr);},0);
in the Promise once 'resolve' is called. I.e. the current execution path must complete before the function passed to 'then' will be executed. Not obvious from the Promise specification why it does this. My guess is it ensures consistent behaviour regarding when 'then' is called (always after current execution thread finishes) which is presumably to allow multiple Promises to be stacked/chained together before kicking off all the 'then' calls in succession.
add a comment |
up vote
0
down vote
up vote
0
down vote
You can see from below the body is executed immediately just by putting synchronous code in the body rather than asynchronous:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
console.log("a");
resolve("promise result");
});
}
doSomethingAsynchronous();console.log("b");
The result shows the promise body is executed immediately (before 'b' is printed):
a
b
The result of the Promise is retained, to be released to a 'then' call for example:
doSomethingAsynchronous().then(function(pr){console.log("c:"+pr);});console.log("b");
Result:
a
b
c:promise result
Same deal with asynchronous code in the body except the indeterminate delay before the promise is fulfilled and 'then' can be called (point 'c'). So 'a' and 'b' would be printed as soon as doSomethingAsynchronous()
returns but 'c' appears only when the promise is fulfilled ('resolve' is called).
What looks odd on the surface, once the call to 'then' is added, is that 'b' is printed before 'c' even when everything is synchronous. Surely 'a' would print, then 'c' and finally 'b'? The reason why 'a', 'b' and 'c' are printed in that order is because no matter whether code in the body is async or sync, the 'then' method is always called asynchronously by the Promise. In my mind, I imagine the 'then' method being invoked by something like setTimeout(function(){then(pr);},0);
in the Promise once 'resolve' is called. I.e. the current execution path must complete before the function passed to 'then' will be executed. Not obvious from the Promise specification why it does this. My guess is it ensures consistent behaviour regarding when 'then' is called (always after current execution thread finishes) which is presumably to allow multiple Promises to be stacked/chained together before kicking off all the 'then' calls in succession.
You can see from below the body is executed immediately just by putting synchronous code in the body rather than asynchronous:
function doSomethingAsynchronous() {
return new Promise((resolve) => {
console.log("a");
resolve("promise result");
});
}
doSomethingAsynchronous();console.log("b");
The result shows the promise body is executed immediately (before 'b' is printed):
a
b
The result of the Promise is retained, to be released to a 'then' call for example:
doSomethingAsynchronous().then(function(pr){console.log("c:"+pr);});console.log("b");
Result:
a
b
c:promise result
Same deal with asynchronous code in the body except the indeterminate delay before the promise is fulfilled and 'then' can be called (point 'c'). So 'a' and 'b' would be printed as soon as doSomethingAsynchronous()
returns but 'c' appears only when the promise is fulfilled ('resolve' is called).
What looks odd on the surface, once the call to 'then' is added, is that 'b' is printed before 'c' even when everything is synchronous. Surely 'a' would print, then 'c' and finally 'b'? The reason why 'a', 'b' and 'c' are printed in that order is because no matter whether code in the body is async or sync, the 'then' method is always called asynchronously by the Promise. In my mind, I imagine the 'then' method being invoked by something like setTimeout(function(){then(pr);},0);
in the Promise once 'resolve' is called. I.e. the current execution path must complete before the function passed to 'then' will be executed. Not obvious from the Promise specification why it does this. My guess is it ensures consistent behaviour regarding when 'then' is called (always after current execution thread finishes) which is presumably to allow multiple Promises to be stacked/chained together before kicking off all the 'then' calls in succession.
edited Nov 9 at 9:24
answered Nov 8 at 9:29
Moika Turns
15329
15329
add a comment |
add a comment |
up vote
-1
down vote
Yes, since the call is synchronous it will be called immediately, before attaching any ".then"s or ".catch"s.
The promise will already be resolved by the time the first ".then" is attached and it will immediately pass down the resolve value.
1
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
add a comment |
up vote
-1
down vote
Yes, since the call is synchronous it will be called immediately, before attaching any ".then"s or ".catch"s.
The promise will already be resolved by the time the first ".then" is attached and it will immediately pass down the resolve value.
1
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
add a comment |
up vote
-1
down vote
up vote
-1
down vote
Yes, since the call is synchronous it will be called immediately, before attaching any ".then"s or ".catch"s.
The promise will already be resolved by the time the first ".then" is attached and it will immediately pass down the resolve value.
Yes, since the call is synchronous it will be called immediately, before attaching any ".then"s or ".catch"s.
The promise will already be resolved by the time the first ".then" is attached and it will immediately pass down the resolve value.
answered Feb 8 '17 at 16:50
epiqueras
520211
520211
1
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
add a comment |
1
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
1
1
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Whether the body is synchronous or async does not matter. The promise constructor doesn't know and won't change behavior.
– ssube
Feb 8 '17 at 16:51
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
Yes, but if doSomeWork() is a callback then it wouldn't be called immediately.
– epiqueras
Feb 8 '17 at 16:53
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f42118900%2fwhen-is-the-body-of-a-promise-executed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
ECMAScript, 25.4.3.1
Promise(executor)
-> Step 9– Andreas
Feb 8 '17 at 16:49
It doesn't matter: if you need to enforce order of operations, do so explicitly. Different implementations will handle promises with slight differences in behavior (bluebird vs native map, for example).
– ssube
Feb 8 '17 at 16:52
@guest271314 I'm writing some tests and need to mock a function that returns a Promise. I want the Promises the mock returns to resolve immediately so that the tests run successfully, so I just wanted to double-check that there wasn't some kind of magic I had to invoke to get them to run.
– Kevin
Feb 8 '17 at 17:21
That, and I want to understand how Promises work under the hood.
– Kevin
Feb 8 '17 at 17:21
2
This may help explain things: stackoverflow.com/questions/42031051/…. It covers a slightly more complicated situation (a promise within a promise), but definitely covers what is going on here, including what happens when a promise resolves before the
.then()
handlers are attached.– jfriend00
Feb 8 '17 at 17:41