4 ms·
No, you won't get the result immediately anyway because then() callbacks are called only on next event loop iteration. This protects from overflowing the stack,
by codedokode 9y ago
No, you won't get the result immediately anyway because then() callbacks are called only on next event loop iteration. This protects from overflowing the stack, but might have small impact on performance.
- deleted 9y ago[deleted]
- saurik 9y agoOK. I see why they would have chosen to do that, and it disappoints me, but it seems to be weirdly more complex than that... this code prints the numbers in order (and continues to do so if you rearrange the calls to setImmediate and setTimeout or move them outside of the function either before or after)... so it is definitely returning from the function but it seems like the resolved value gets to jump the queue? (async () => { setImmediate(function() { console.log("4"); }); setTimeout(function() { console.log("3"); }, 0); console.log(await new Promise((resolve, reject) => { console.log("0"); resolve("2"); })); })().catch(); console.log("1");
- codedokode 9y agoI don't think it is a good idea to expect some specific order in executing callbacks here unless it is described in some specification.
- rmrfrmrf 9y agoThis isn't correct for native Promises. Native Promises flatten themselves out at the end of each tick and will do any synchronous work possible before either the Promise settles or there's something that needs to get thrown to the event queue. This all happens synchronously, although deferred, but still can block the app completely if someone is simply wrapping synchronous actions in Promises expecting them to be "async".