Promises Overview

[00:00:00]
>> Will Sentance: You know, one thing to share here, I didn't really stress enough, forgive me, is that these callback functions, we saw like before, a function is passed to our setTimeout, and it is now, now we don't mind this name. Now it is called back in to JavaScript land. This feels a lot more like a reasonable meaning of the word callback, but we use it, as we saw yesterday in higher-order functions as well, but this approach was the standard approach for interacting with the outside world of JavaScript, the outside world of the web browser from within JavaScript.

[00:00:32]
This was the standard approach until ES6. In ES5 and before, and setTimeout still works this way, how do we do it? We pass in a function, our facade function, set up work in the background, and more or less did nothing of interest in JavaScript. Now that can be a problem because what if I'm, I mean, it's a bit odd that you could have tons of background work going on and within JavaScript, no serious way of tracking the work you're doing.

[00:01:05]
That feels, you know, not ideal. So problems, and another problem, our response data, so a lot of these background tasks go off, in this case, we didn't really have any data to retrieve, but a lot of these background tasks go off and get data from a network. The only place that data is going to be available in is the function that runs on completion. That's where it's going to populate, but we'll see that later.

[00:01:28]
That was a bit of a problem, it meant that within this style. We had a problem where when the print hell function ran, for example, if that instead had been off to get a network piece of data from TikTok, we'd come back with that data, it would only be available inside that associated function. I mean, that's also, by design, where else is it going to go? But that could be a problem. We'll see a solution in a moment.

[00:01:56]
They call that callback hell. Maybe this is a slightly strange mental model, the idea of, they call it passing control, right, like you're passing a function into another function only for it to run actually much later, it certainly looks confusing that that print hello timeout 0 looks like it's going to call print hell right there and then, but because it's been passed out into the browser, and being brought back, brought back in later and only executed when the event loop sees the call stack is clear and global code has finished running, because of that.

[00:02:35]
It ain't the most intuitive approach, the most intuitive design. Now what I would pitch for you is it's super explicit once you understand how it works under the hood. One queue, background work, all of these facade functions, set up background work, when they complete in the background, then they get passed to the queue, where they sit until all global code has finished running. We have complete confidence in order of execution, if not the exact timing, I can't tell you when, you know, work after the network would complete, but I can tell you it will only ever run in JavaScript once all my regular code has finished running.

[00:03:20]
But in ES6 and beyond, we got introduced a new approach, that of promises. These are what I call two-pronged facade functions. They have consequences both within the web browser, because they're heading off to do some stuff outside of JavaScript, but they also, so they initiate some background web browser work, that means like setting up a timer, speaking to the network, but they also return a placeholder in JavaScript, an object, a special type of object known as a promise, immediately that allows us to, A, know that we've done, set up some background work and keep track of the fact that we've done that within JavaScript, that's quite nice.

[00:04:02]
And B, is going to open up ways of interacting with the data that does get retrieved, potentially from the background work from, let's say TikTok server. Open up ways that we can interact with that that look on the page much more readable. I would argue they actually obscure even more what's really going on because in under the hood, it's going to all be just the same as this, well, with some key new cues, but nevertheless, this has become the standard approach, and it replaced what we used to use for accessing the network known as XHR with our new promise approach, which is achieved through the built-in two-pronged facade function known as wat.

[00:04:53]
We don't use XHR anymore for accessing the network, Chris, we use wat. Fetch, we use fetch, exactly. So, here we go, ES6 onwards, promises. We are now going to introduce the five letters, F E T C H fetch, that I think do the most stuff of any five letters in JavaScript. They are going to kick off background work, speaking to the internet, speaking to TikTok. They're at the same time going to have an effect directly in JavaScript.

[00:05:23]
You can see that because when I call fetch my two-pronged facade function, not only am I going to be setting up some work in the background, but I'm also going to be assigning its immediate return, not the data, but its immediate return, because the data work is going to the, the TikTok data is going to be all off down here in the web browser. But I'm immediately going to assign to future data a special object, this is its other prong, I call them two-pronged, one prong goes off to the web browser and does stuff, the other prong goes and returns an immediate object into future data.

[00:06:06]
And that object is going to act as a placeholder for the data from speaking to TikTok, and when it returns, hopefully we can use that data in some sort of way. But in practice, people, this is still a law of JavaScript, which is synchronous here. Background work comes back in asynchronously out of order, so under the hood, even though this looks, I mean, you look at this, you might be like, wait, when future data comes back, we're going to display it.

[00:06:34]
Are we doing it right there? Even though this code looks more linear and intuitive under the hood, we're going to have very, very similar pattern to what we've just seen.