Is my understanding of asynchronous operations correct? [closed]

Answer 1

This page explains Node.js event loop very well (since it's by Node.js):

https://nodejs.dev/learn/the-nodejs-event-loop

A problem can occur if a piece of code takes a long time to complete. This is because i) it stops code below from running and it might be nice to run this whilst the hard code loads in the background. And ii) Indeed, JS might try to execute the code below before the hard code’s finished. If the code below relies on the hard code, that’s a problem.

Yes, though to reword: having a user wait for code to resolve is bad user experience rather than a runtime error. Still, a runtime error would indeed occur if a code block was dependent on a variable that returned undefined because it had yet to resolve.

A solution is: if an operation takes a long time to complete, you want to process it in a separate thread while the original thread is processed. Just make sure the main thread doesn't reference things that the asynchronous operation returns. JS employs event-ques for this solution. Asynchronous operations are executed in an event-que which executes after the main-thread.

Yes, but it is important to point out these other threads are occurring in the browser or on an api server, not within your JS script. Also, async functions are still called in the main call stack, but their resolve is placed in either the job queue or message queue.

But even the event-que can suffer from the same problem as the main-thread. If fetch1, which is positioned above fetch2, takes a long time to return a promise, and fetch2 doesn’t, JS might start executing fetch2 before executing fetch1. This is where Promise.all is useful because it won't proceed with the next step in the asynchronous operation until both both fetch1 & fetch2’s promises are resolved.

Yes, a promise's resolve is executed as soon as the current function in the call stack resolves. If one promise resolves before another, its resolve will executed first event if it was called second. Also note that Promise.all doesn't change the resolve time, but rather returns the resolves together in the order their promise was executed.

On a separate note, I’ve read when chaining .then, that counts as one asynchronous operation so we can always guarantee that the subsequent .thenwill only execute when the .then before it has executed|resolved its promise.

Yes, though the newer and cleaner syntax is async await:

function A () {
  return new Promise((resolve, reject)=> setTimeout(()=> resolve("done"),2000))
}

async function B () {
  try {
    console.log("waiting...");
    const result = await A();
    console.log(result);
  } catch (e) {
    console.log(e);
  }
}

B();

And below shows the Node.js callstack in action:

function A () {
  return new Promise((resolve, reject)=> resolve(console.log("A")))
}

function B () {
  console.log("B");
  C();
}

function C () {
  console.log("C"); 
}

function D () {
  setTimeout(()=> console.log("D"),0);
}


B();
D();
A();
 

B gets called, C gets called, B resolves, D gets called, setTimeout gets called but its resolve is moved to the message queue, D resolves, A gets called, the promise gets called and immediately resolves, A resolves, the call stack completes, the message queue is accessed