That’s right! Promise is all about waiting for feedback.
Today we will be talking what a promise is and also about the following types of promises:
Before we talk about any of this, let’s understand what a promise is.
A promise is an object that will return a resolved object or reject an object sometime in the future.
To put it simply, a request is made and this request, once completed, will tell us if it is successful or not.
Let’s look at the following example:
Hm…where are the promises? Sure, I am fetching data but I am not seeing the “promise” keyword.
That’s because the fetch call itself returns a promise. Promise has two functions, one is called then and the other one is called catch.
When we fetch a URL and call .then, we are offering a function as a parameter, where the function takes in the response returned by the fetch call. Here, we get the data from the API successfully and we generally set it to some local state to store this piece of information.
Quick question: why do we trigger two .then calls?
With fetch calls, if successful, returns a promise with the response. But this response is not formatted in a way our UI can consume. As a result, we need to call res.json(), which returns another successful/resolved response with the data we need.
.catch is another method the promise contains. This function accepts a function with error as its parameter. This error is provided by the promise when it throws a reject value(or in normal English term, the API call failed).
Now we understand how a promise works. Let’s revisit the following type of promise calls:
Promise.all takes in a set of promises and returns a promise that will resolve to success if all of these promises resolve. If any of the promises fail, then Promise.all will return a reject/failed promise.
Here’s an example of a successful and failed Promise.all example:
When’s a good time to use Promise.all?
Let’s say you have a list of API calls that have to occur in a sequential order. Generally, you have to chain all these promises in the following manner:
What if we have to toggle around 10, or maybe even 20 promises? If one of these promises in the chain is not set up properly, it will be a pain to go through the list of promises and find the problematic one. Most importantly, if all these promises are dependent on each other to execute properly, then promise.all is best fit for this kind of scenario.
With a given array of promises, Promise.allSettled resolves automatically when all the promises have either been resolved or rejected.
Here’s an example of promised.allSettled:
One key point, Promise.allSettled never returns any failed promises, regardless of their results of individual promises.
One might ask: when are promise.allSettled used?
Let’s say you have a software application and you have to install a set of software to finishing install one big software. If all of these software are not installed properly, then you cannot say your overall installation is complete. As a result, you need to use promise.allSettled to ensure certain actions can be taken(for example, throwing a popup either saying the installation is complete or failed) if and only if all the promises are either resolved or rejected.
Given several promises, Promise.any returns a promise if any one of the promises resolves/fulfills. It returns a rejected promise if all of these promises are rejected.
Let’s take a further look at the following example:
Here we have three scenarios: one with all success promises, one with a success promise followed by a failed promise, and another one with all failed responses.
As you can see, Promise.any with promise 1 and 2 and promise 5and 6 have succeed while Promise.any with promise 3 and 4 failed.
Quick Question: where do we use promise.any?
Let’s say you are on a chess gaming application waiting to match up with any players online. Behind the scene, the application might be making multiple API calls for all the players within the radius.
Once you are matched up with a player, does it matter if you are matched up with all the other players out there? Not really. You can imagine a match up as an API call that will return a promise. Once any of the promise returns (getting matched up to a player in a chess game), the rest doesn’t matter even if you are able to match up with other players.
Promise.race returns a promise as soon as one of the promises either rejects or fulfills, with the result being the value/reason of the promise that resolves/rejects first.
Let’s take a look at the following example:
Over here, we set PromiseTwo to execute after 6000 ms on timeout. As a result, Promise one gets executed first, and as a result Promise.race returns a resolved value.
On the other hand, promiseFour executes before promiseThree does. As a result, Promise.race returns a failed promise as a result of promiseFour being executed first.