Check out a free preview of the full The Hard Parts of Asynchronous JavaScript course

The "Promises" Lesson is part of the full, The Hard Parts of Asynchronous JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Will illustrates how Promises work to create a two-pronged façade functions that both initiate background web browser work and return a placeholder object immediately within JavaScript.


Transcript from the "Promises" Lesson

>> Will Sentance: Solution 3: Using two-pronged, they do two things at the same time, they do two things at the same time. One in JavaScript, one outside of Java on the web browser. Facade functions that both initiate background web browser work and in JavaScript, return a placeholder object known as a promise object immediately, that's gonna be filled in later on.

With a value from the background web browser work, web browser features work. Okay, here we go. We're gonna walk through it very precisely. Line one, Michele who knows to do this very slowly. Michele, what are we doing very slowly in our first, I'm just gonna go slowly as well.

Very slowly Michelle, in our first line of code, Michelle. What are we doing?
>> [LAUGH]
>> Will Sentance: In our first ally go, Michelle?
>> Michelle: We are using JavaScript to declare [LAUGH] in memory-
>> Will Sentance: Very good, that's very explicit, excellent. A function that we are calling display. We're naming it, be careful, I say calling as well, but that sort of indicates we're running it.

>> Will Sentance: We're naming display, because we might be confused to say we're executing it, we're calling it. No, we're just naming it, display. I knew you weren't implying that, but just to be clear, display is saved excellent. Next line, Brian, left-hand side first.
>> Brian: We are clearing a constant name future data.

>> Will Sentance: Excellent. Okay, it's going to be what in the more general sense? Well what is it, it's always gonna be the outcome of the right hand side's work, so it's a return value of the right hand side execution of fetch.
>> Michelle: Yes.
>> Will Sentance: Good, you maybe meant to say that so, I apologize if you were.

But for now, it's going to be what?.
>> Brian: Undefined.
>> Will Sentance: Undefined, we don't yet know what to store there, correct. We're gonna go do some work on the right-hand side. So we are going to start running a function, fetch. Now who thinks this function fetch creates an execution context in a way that we're used to?

Raise your hands. No, instead, thank you James for being kind to give us somebody. Instead fetch is what? Fetch is a facade function. A facade for some work, actually I suppose it could create an execution context for this in the sense we're used to, but it's still something beyond our control.

We did not write fetch, this is a function that is masking a bunch of JavaScript work, we're going to see that in a second, and a bunch of web browser work. And by the way, we're hoping with the way fetch, fetch is this new feature of the browser and of JavaScript, we're hoping it's gonna return us data from Twitter and hopefully a tweet.

That's pretty clear, that's what we hope it's gonna do. Okay, so first function's fetch, let's start doing it's work. We're gonna try to be as complete as possible here, and this is where thoughts get complicated. So future data is going to be the return value in JavaScript of calling fetch, this new web browser feature that has the JavaScript label for the feature.

The label in JavaScript is known as fetch. Who knows, what the web browser feature is, that fetch kicks off or gets started? Cuz it's not called fetch. Who knows what the web browser feature is called?
>> Paul: xhr.
>> Will Sentance: It is xhr, well done Paul. It's XMLHttpRequest. We'll see what that stands for in a second, well, it sounds like, we'll see what each of those words mean.

To be honest they all stand for stuff, XML, HTTP, are all new words. Request obviously isn't. That would be interesting if it were, though. Maybe it is. Maybe request is an acronym.
>> Will Sentance: All right, good, so this is gonna do something in JavaScript immediately. Set timer, it didn't, set timer just spun up our web browser feature.

This little guy here, fetch, though is gonna do a bunch of stuff in JavaScript. It's going to immediately return out an object, immediately return on object with a property on it called value, that is undefined. This is where the result of this data, or the result of fetch's background work is gonna store our resultant value from the background work, when it comes back.

The background work being speaking to Twitter's server, bringing back a tweet. That's gonna be filled in here. It's also got a property on it, it's a hidden property called on fulfillment. Which is an array, a list, an empty array, into which we can stick any functions, but we want to also trigger when the value gets updated.

The design of this special object, the new type of object in JavaScript known as a promise object. Its design is such that when its value gets filled in, then it's gonna trigger all the functions in this on fulfillment array. Now, the reason we want to do that is this return dot object is gonna be stored in future data.

Sunni, where's the return of that object from calling fetch going to be stored?
>> Sunni: Fetch data. I'm sorry, future data.
>> Will Sentance: Future data, exactly. So we might think I could go display futureData.value. But the problem is I've no idea when that value is going to be updated. So, there's no way in my regular code I can write futureData.value, and then that's gonna be my return tweet.

Say hi, for example, and then run display on that. But that's my goal. I'm only giving the data back, so I can run functionality on it. So if I don't know when that data's gonna come back, I can't in my regular ordered synchronous thread of code right, display and pass in futureData.value, cuz I have no idea when value's.

I could try and hold off writing like till the very bottom of my code display(futureData.value), which will be the value that gets thrown in. But when can I run this? I never know when that date is going to come back. So if I want to run functionality on my data when it comes back from the background work, the only place I know that the value is definitely filled in, the only place it really definitely knows is this object.

So we're going to attach to that object functions into this array. You're gonna push them into that array. That are going to be auto-triggered. When the value gets updated. See it feels a lot like the thing we were doing before honestly. We're not gonna be able to do this, cuz I still gave no idea when that value's gonna be updated.

So the only place I know for sure that the value's been updated, the only time I know for sure is on this object when that value gets filled in, and then auto trigger all these functions to run. And that's the very design of this object, this new promise object in JavaScript.

When value gets updated, trigger all my functions. By the way, with value, as those functions input. Right now we have no functions in there, but we better add some. So that is the object that comes out. It's known as a promise object, excellent.
>> Will Sentance: So, and that gets stored, as Sonia rightly said, into future data.

There it is in future data. It has a value property, which is undefined. It has two placeholders basically, two things that are waiting for stuff. And it has a property which is hidden called on fulfillment, that is basically a list into which we can put any functions we want to auto trigger when value gets updated.

And value will be updated, when our web browser feature gets back its results. So let's hope fetch also what, is two pronged It also initiates a background web browser feature which was which, Paul?
>> Paul: XML HTTP request.
>> Will Sentance: XML HTTP requests, excellent. So it has two consequences, one in JavaScript.

I might even write that actually. One in JavaScript and one in the web browser, one in the web browser, web browser. Which is exactly as Paul said, XML HTTP request, what's that mean? XML is the former of the data, that we're gonna go and get from the Internet, when we're dealing with web browser stuff.

HTTP is the protocol, P stands for protocol. That means the rules of the game for how we can go and get and bring back data over the web and request is request, go and get data, good. So, lets followup two things, let's keep track of it down here.

So xhr is the web browser feature we're using. It's job, it's a special feature of the browser, the most important feature of all. Quite clearly, right? It's the one that speaks to the internet. That's it's job. So it's spinning that one up. What information does it need to know, Ben?

>> Ben: URL.
>> Will Sentance: URL, excellent, thank you, Ben. The URL, which is, and also the path /will. And also, what's the other thing it needs to know, Ben?
>> Will Sentance: Fetch to folks to it, actually, anyone know, James?
>> James: Method.
>> Will Sentance: Method, which is get, that's to say it's gonna get some data, not send or post like a new tweet, it's gonna get tweets back.

And fetch to folks to get, okay. Is it complete yet, Ben?
>> Ben: No.
>> Will Sentance: Definitely not, right, 1 millisecond, we're at 1 millisecond here. It definitely complete the one millisecond, right? It's gonna, let's say 200 millisecond, it's gonna take or something like that. On completion, and here is the toughly, on completion, Ben, what's do we want this to do?

On completion when they come back, what do we want to do with that data?
>> Ben: We want to assign the response data to value?
>> Will Sentance: Is he right? He is spot on. On what object?
>> Ben: Value. The promise object.
>> Will Sentance: Which is known as?
>> Ben: Future data.
>> Will Sentance: Excellent from Ben.

We're going to update futureData.value, is going to be whatever data we get back from our message. Our HTTP message to Twitter. There it is, the Twitter. To their computers. When that data comes back, it's gonna fill in the value property of our future data object, which is then going to do what, Ben?

>> Ben: It's going to trigger on fulfillment functions?
>> Will Sentance: All the functions in our fulfillment array. Exactly.
>> Will Sentance: Very good. Very good. Can we talk about though how much that single fetch segment is doing? It is a two pronged facade function, not only is it doing stuff in the web browser, it's also doing stuff in JavaScript.

So that we have in JavaScript ready a little space into which our function, into which our return value, our response object. That's the response we get from speaking to Twitter in the form of an object, is gonna be stored in that value property. Right now it's undefined. Right now we've not even said what we're gonna trigger.

But we will in a second. Okay, excellent, well browser feature stuff is finished. That was what fetch set up. The JavaScript stuff instantly returned future data. And so we're able to move on to our next line in our JavaScript thread, which says to do what, Blessing? We did future data, with the return value of fetch, which is the object placer object.

What's our next line, Blessing?
>> Blessing: The carded versionality on the future data.
>> Will Sentance: Excellent. My least favorite name method in JavaScript, .then. Everything it's doing is telling you, that it's job is somehow, I really dislike it, it makes people think that we're gonna somehow return to that line and then call display.

It is fundamentally not doing that, what is then doing? Well, Ben, where do we put functions that we want to be auto-triggered, when our value property of future data gets updated from the background work?
>> Ben: Into the future data object's.
>> Will Sentance: Excellent. How do we get them in there?

Well, that is the job of this built in function, then. I don't recall if the server function implies this sort of facade for web browser or if it's not. It's a bunch of JavaScript code written to do this. It's written to, so this is future data, this object here.

The same object just we pass it out and we store it in future data. It has a property on it called on fulfillment, which is an empty array. All that then does, is it says whatever you pass to me whatever function definition, we're not running display here. What symbols tell my I'm running a function, Josh what special symbols say run a function?

>> Josh: The parenthesis.
>> Will Sentance: Parenthesis, I see no parenthesis here, so we are not running display. All we are doing is a whole function definition, into that array. That's all that then is doing. I would replace name then with store function we want to auto trigger, on value probably being updated.

It's not a catchy method name, but it is an accurate method name. Into it goes, that is to say we put In the on fulfillment array, the display functionality. That's now gonna mean when our value gets updated, we are gonna call display and its input, its argument. Right now, the parameter's data, that's gonna be thrown out and replaced with whatever the value is.

And how do we get that display function in the on fulfillment list of functions. How do we get it in there? Using the then method. To whatever you pass as their method will be thrown into the object on the left hand sides on fulfillment array. Hold on one second, Josh.

All right, it attaches display functionality to future data. It is absolutely not saying, run display right now. It feels so much, I mean you look at this and go well future data comes back and then we need to run display. Yes, in theory, in a broader metaphorical sense yes.

But no, what we're actually doing is we got into futureData a promise object with a value property that's not yet filled in. When it does get filled in, we're gonna trigger all these functions. How do we get functions in there? Using the then method on the futureData object.

Okay, which means now we can continue the hell on with our synchronous code and at 2 milliseconds, what we've done for you today .then, what line of code do we hit at 2 milliseconds, Bryan?
>> Brian: Console.log.
>> Will Sentance: Console.log, yeah.
>> Brian: Me first.
>> Will Sentance: Console.log me first, excellent. Console.log me first.

There it is at 2 milliseconds. Brian, have we achieved our very, very important goal of being able to set up tasks that take a long time, and yet continue our regular JavaScript code?
>> Brian: Yes.
>> Will Sentance: In a non-blocking way. Exellent, we have. You're spot on. At 2 milliseconds we continue the hell on with our code.

Okay, and now in JavaScript, we're pretty clear. Honestly, we're pretty clear right now. Okay, but in our background web browser feature, a world of stuff is going on. Twitter's server is sending us back a response at maybe 201 milliseconds, something like that, plus 200 milliseconds,
>> Will Sentance: That comes, our response which is my ever simple response thing of hi.

Now obviously, it comes back, to be really clear, when it comes back as an object when we got to go in and find the actual value in the body. But we're just gonna simplify it and say it comes back as a pretty string hi. So Rick at that point therefore, if we've just got our response subject back has our background xhr task, the request of data, we got the data back.

Has it completed?
>> Rick: Yes.
>> Will Sentance: It has completed, spot on. It's completed and so, Ben, what are we going to trigger happening?
>> Rick: We're going to assign that string to futureData.value.
>> Will Sentance: Excellent, very good communication, yes, correct. Which means.
>> Will Sentance: What are we gonna trigger running? Blessing, be as simple as possible here, what are we gonna trigger running at this point?

>> Blessing: Okay, now that the value has come back, we're going to trigger the display function.
>> Will Sentance: Exactly, now we're gonna hold on, for now we're just gonna say we're gonna trigger it. We came back at about what, 201 milliseconds. We're gonna trigger it to run at 200 milliseconds.

We're gonna discover, do we really think the JavaScript's gonna allow that function straight back in? Or is there gonna be some intermediate step? Maybe, but for now let's just say, we trigger running display, with hi, right? We look at the function display that we're triggering. We see its parameter is data.

We call it. The parameter data gets replaced by the value what, Victor?
>> Victor: Hi.
>> Will Sentance: Hi, excellent. Excellent, and therefore in our memory, we have the parameter data with a value, hi. And were going to console.log, at 201 milliseconds.
>> Will Sentance: Our value of.
>> Will Sentance: Hi, there it is people, my goodness.

>> Will Sentance: We've achieved our three goals, one, set of tasks that takes a long time in web browser, two continue running through JavaScript code, it hits me first, no problem, without blocking. Three, when that data comes back from the background task, no where is it going to show up and then auto-trigger functionality at that moment with that data's input.

I'll tell you this. It looks very similar, by the way, to the previous model. We've just now got an intermediate step. We now just update a value in JavaScript that auto-triggers the function. Before, if you remember, with set timeout, we pass a function in that would be auto-triggered with the value.

Now we pass a reference to a position in JavaScript memory, a value property that gets filled in on completion. And that's what triggers the function to call. I don't know. Improve readability maybe.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now