Understanding JS Promise Methods and the Importance of Event Loop

Promises are a fundamental part of asynchronous programming in JavaScript, and their associated methods – Promise.all, Promise.race, and Promise.allSettled – offer unique ways to manage multiple promises concurrently. However, each of these methods comes with its own set of caveats.

Let's consider three promises for our examples:

const promise1 = Promise.resolve('Resolved Immediately');
const promise2 = new Promise((resolve) => setTimeout(() => resolve('Resolved after setTimeout'), 0));
const promise3 = Promise.reject('Rejected Immediately');        

Promise.all: It returns a new promise that resolves when all promises are fulfilled, or rejects as soon as one promise rejects. This is great when all promises must succeed. However, there are two main drawbacks to this approach. The first is if just one promise fails, the entire operation is considered a failure, which might not be desirable in certain scenarios. The second is if one promise takes long to complete, all promises will resolve only when that one slow promise resolves.

Promise.all([promise1, promise2, promise3])
 .then(values => console.log('all completed ??', values))
 .catch(error => console.log('??', error));        

The following code will resolve to:

Rejected Immediately ??        

Promise.race: It returns a promise that settles as soon as one promise settles, whether it's fulfilled or rejected. This is useful when you're interested in the fastest promise. However, it's crucial to note that Promise.race will completely ignore the results of all other promises as soon as the first one settles, potentially leading to overlooked errors or results.

Promise.race([promise1, promise2, promise3]
 .then(value => console.log(value))
 .catch(error => console.log(error));)        

The following code resolves to:

Resolved Immediately ??        

Promise.allSettled: It returns a promise that settles when all promises have settled, regardless of whether they're fulfilled or rejected. This is beneficial when you need to know the outcome of all promises. The downside, however, is that you'll need additional processing to distinguish between the resolved and rejected promises, as Promise.allSettled doesn't inherently differentiate between the two.

[
? { status: 'fulfilled', value: 'Resolved Immediately' },
? { status: 'fulfilled', value: 'Resolved after setTimeout' },
? { status: 'rejected', reason: 'Rejected Immediately' }
]        

And as the last note, why do Promises execute before setTimeout?

Event Loop & Task Queues: JavaScript, despite being single-threaded, leverages the Event Loop to handle asynchronous events. It continuously checks the call stack and, once it's empty, pushes the first task from the task queues (Macro and Micro) onto it.

Macro tasks are tasks like setTimeout, setInterval, I/O operations, and UI rendering. Additionally, each new script run is also considered a macro task.

Micro tasks include process.nextTick, Promises, MutationObserver, and others. These tasks are processed after the current task finishes and before the Event Loop is allowed to continue.

Here's the key point: Promises are considered Micro tasks, while setTimeout events are categorized as Macro tasks. Consequently, the Event Loop prioritizes completing all Micro tasks (Promises) in the queue before moving on to the next Macro task (like setTimeout), even if the delay specified in setTimeout is zero. This is the reason Promises are executed before setTimeout.