Promises: allSettled, any, & finally

[00:00:00]
>> Maximiliano Firtman: Some improvements that appear to this promise pattern later. For example, one of the great advantages of promises that I didn't mention yet, there are a couple of advantages. One is that we can have, compared with call backs for example, we can have a common vocabulary. I don't need documentation.

[00:00:23]
Let me explain what I'm saying. So for example, I'm not sure if you even remember jQuery those times. But for example, to make a fetch, there were many ways to do that, but one was to do a .get or .ajax or just think about that there is something like this, where you pass a URL and then a callback.

[00:00:49]
Okay, so I create a function that will receive the data something that, think about this okay? But then you have Nodo.js, for example, Node.js without promises like reading a file It's something like this, you read the file, okay, and then you pass the name of the file.

[00:01:06]
By the way, if let's say that in jQuery, if there is an error, you receive a second callback with the error, okay? So you have two callbacks as two different arguments. Make sense? Callback for on OK, callback for on error. On Node.js you wanna read the file, and then, I'm not sure if you remember how that works, you don't receive two callbacks.

[00:01:31]
It's just one callback, where you receive the error or the reference to the file. I mean, maybe it's not the 100% the right code, it was just to give you an idea. So the problem with callbacks is that there is no unique design pattern. Every API designer can pick its own solution.

[00:01:52]
And in this case, you see it's different. How can I know when I'm calling an async API how to, for example, catch errors. Well, you need to read the documentation. With promises, you have only one way. If it's a promise, you know how, it's a dot catch or the try catch, if you're using async await, okay?

[00:02:13]
That's okay, so that's the only way. So that's one great advantages of promises over call backs. And the other great advantage is how to work with several promises at the same time. Let's say, I need to go and grab from the network three different JSON files, and I wanna do something when I have all the three.

[00:02:35]
With callbacks, it's a mess because, of course you can request three, fetches or whatever, three files, but you're receiving the responses in any order because you wanna do this in parallel, okay? So I just make three HTTP requests and let's wait for them. How can I know when all the three are done?

[00:03:00]
Every time I'm receiving one response, I need to check what happens with the other two manually. And if the other two are okay, okay, I'm the last one. So let's do the job. With promises, the great advantage is that we have ways and the API has ways to actually wait for all the promises at the same time.

[00:03:21]
So, and there are many ways that you have in the promise pattern to do that. And now we have from ES6 more ways. For example, we have the Promise.allSettled, where I can pass an array of promises
>> Maximiliano Firtman: That in this case, these are two promises that are just rejecting and resolving immediately, but it can be different fetch APIs where you're fetching from the network, something like that.

[00:03:52]
>> Maximiliano Firtman: So you can wait for all the promises to fulfill or now there is .allSettled. .allSettled will say when all the promises ended. Rejected or settled? I don't know. So all of them have finished. When all of them have finished, that's give me another promise. And of course, I can use async await.

[00:04:18]
Does it make sense? Any will give you the first one. You use that with a design pattern known as a race. So I have a race between two different patterns or two different ways to access the data. A very simple to understand use case It's data that you have cached locally in the database and also in the network.

[00:04:46]
So I start to race. Let's grab the data from the cache or from a local file and from the network. Wherever it comes first is the one I'm going to use. So for that, you create two promises, and then, so here I can create an array of two promises, like get from database and also fetch.

[00:05:10]
And the first one is the one that will win and will give me the value. That's promise.any, you pass an array of promises, of course, the rest will be discarded.
>> Maximiliano Firtman: Does it make sense? So working with multiple promises it's a nice way also, that give us an idea that it's a good idea to move all your synchronous code to promises as well.

[00:05:38]
So, if you have for example, an array of countries, okay? So you have an array of countries, and you create the array of countries like this, right? And you hard code your countries, and it's fine. Of course, we'll start with Argentina, not because it's my country, it's with A, right?

[00:05:57]
Then a Brazil, one per, I don't know, Canada and so on. So you hardcode the array of countries. Well, it's a better pattern, there is a design pattern known as promisify that's the promisify data. So and that design pattern promisify data. Well tell you this, instead of doing this, create a function, get countries,
>> Maximiliano Firtman: And you say okay, so I create a function, and then I return the array, no, don't do that, because that's kind of the same thing.

[00:06:41]
Always return a promise. So I can return a promise that right now fulfill with this. Or if you wanna see the previous code that we did, I returned a new promise. That resolve rechecked and we're just going to resolve with this. So in this case, the array is a synchronous array.

[00:07:17]
I'm not going to a database or a network, but I can still promisify It.
>> Maximiliano Firtman: What's the advantage of doing that? I'm ready for the future, so if you promisify all your data later, if you want to change to a database and then your countries will be in a database, it's easy to change that.

[00:07:40]
You don't need to change the consumers of the data. Everything will be async await. Even if it's a synchronous operation, there is no real performance penalty, or the performance penalty is really, really small to think about it.