DEV Community

Discussion on: ⭐️🎀 JavaScript Visualized: Promises & Async/Await

Collapse
thumbone profile image
Bernd Wechner • Edited on

Love it! Awesome piece. I have some residual questions. It's an old article so not sure if you're still around watching and noticing comments and questions. We shall see.

  1. The first relates to the stack. it would help to have another layer of function call to better illustrate the stack with contents, but that aside, I have often seen something like main() which alludes to what you've called the Global Execution Context at the bottom of the stack. For the simple reason that it's commonly written that the event loop regains control (and checks the microtask queue) when the stack is empty. I wonder if you have thoughts on that?

  2. the async/await visualisations are awesome beyond any I have seen yet! I wonder if you would continue with one more article, that covers .then() with this level of clarity.

  3. For all it's awesomeness I am still struggling to understand exactly how the two executor callbacks work, most especially with regard to timing, and the microtask queue. Here is my musing (current thinking) which I'm looking to confirm or correct: When the promise is instantiated it passes a two default callbacks to the executor, and runs the executor immediately (on the stack). A call to the first argument will have the Promise update it's state from "pending" to "fulfilled" and a call to the second will have it updated to "rejected". When the executor is finished (returns) it should have called one of these (or the promise will never resolve). After it has finished the instantiator returns and the promise is one of its three states. A call to .then() (optional) will register one or two callback handlers (for fulfilled and rejected). If the state of the promise is currently fulfilled or rejected it will immediately queues the appropriate callback onto the microtasks queue and return. If the state is pending, then the Promise itself will, as soon as its resolver or rejecter are called queue the appropriate callback then. I'm not sure if that's entirely accurate and would love to see it documented as well as you have if it is, and or what is right if it's not.

  4. When await is used, there is a situation I'm not clear on too. Await works a bit like yield I'm told, and it seems maintains the state of the running async function (on the heap one presumes) and as you write puts the async function on the microtask queue to continue at the same line (which the preserved state enables, though said state could be on the heap or on the microtask queue who knows?). In your example the function one resolves quickly, instantly, but if the function we are waiting on is still pending when the async function reaches the head of the microtask queue and runs once more, what then? I would guess it simply requeues itself. But it would be great to know and to have whatever happens there, so excellently illustrated as you have.

I would be so thrilled if you lent you expert hand at illustrating answers to these. Many many thnaks for the awesome work you have done to date!