Deferred Promise Functionality

[00:00:00]
>> Will Sentance: Oh my goodness, thumbs in a second on what we have done here. We now have a new way of setting up background work in the web browser that not only sets up the background work, but also in the foreground creates an object that acts as a placeholder for the data when it returns, is retrieved from speaking to TikTok, and is automatically filled in with that data at the moment of completion of that background work.

[00:00:34]
Okay, great, but what can we do with it? Don't panic, we also got the ability through then to add a function to the list of functions that would automatically be triggered to run at that moment of the value property, the result property being filled in with cute puppy, I retrieve data, which was automatically run. How do we run? Well, we add to the call stack. Hm, straight there? Well, we'll see. We add to the call stack and add parens to it, we didn't have to do that, JavaScript did it, and we didn't have to insert the data automatically, it was done for us by JavaScript, brand new execution context.

[00:01:12]
We made sure we had a placeholder ready, our data parameter, and it got filled in with that cute puppy string, the data we got back from TikTok and was. You know, I should have done my cute puppy in purple. So cute puppy, there it is, cute puppy, here's our data that came back. Cute puppy, cute puppy, cute puppy. There we go, cute puppy, cute puppy. And there it was, our cute puppy was filled in here.

[00:01:43]
That was the update on completion, go back into JavaScript, find the future data object, set the result value to the string of data we got back, automatically trigger the display function that we added to future data's objects, list of functions to run on completion through the then method, and then that function was automatically run with that input data. People, let's have thumbs, you lost me. I do not like speaking to the outside world.

[00:02:12]
I'm clear, I have clarifications. I'm seeing a lot of thumbs up. Tenzin's got a clarification, Joe has one, Joe, give us a clarification. So yesterday we, every time we were talking about what we were writing to memory, we were really looking at it within the scope of the execution context within which that memory was being used. We had our local memory, we had our, you know, global scope memory. Now, in this example, future data is being established within the global scope of memory, and yet the web browser also seems to have access to it outside of relying on the callback queue tacking it on at the very end because we're updating the result of future data on completion, not programmatically within global but simultaneously from the web browser.

[00:03:05]
So I guess I'm just a little bit curious about when we declare future data and we invoke fetch, the return value of fetch, is there something about that object that sets the scope as wider than the global context, oh. Uh, sets the access to, yeah, it is the, this object we have in our web browser API because this fetch. Uh, two-pronged facade function got us both the JavaScript object and our network work in the background.

[00:03:43]
These two are intimately connected, and I will say. I'm going to do the implementation. Uh, in terms of exactly how it gets that reference back, all that we need to know is that on completion, because this promised object was produced by the same fetch call, in fact, it has two consequences, as a network request, this network request maintains a reference to a link back to this saved object. And that allows it to then update that property.

[00:04:15]
Now how is that possible in the broader sense, because JavaScript is running within this larger system known as the web browser, and this interfacing between the two of them is, and that is a quote, implementation detail, that is a. Uh, the reality of running a runtime within the browser as a whole, you're able to, from the browser APIs make references back to positions in JavaScript memory, and that's exactly what the browser is doing here.

[00:04:43]
That allows it to, when it completes the work, go and update the JavaScript object. It is absolutely not getting a copy of this object in the browser, only a reference to that position in JavaScript memory. One second, Chris, with Tenzin first. Oh yeah, I just have a hypothetical scenario. Um, let's say you have two separate calls to two different URLs. The data from those two URLs to interact with each other.

[00:05:10]
How would you do that so that you don't. Kinda, in a, in an asynchronous way. Yeah, absolutely, we're going to see that on the very next slide, because, flipping heck, if you hadn't spotted yet. The uh similarity to our old callback style, where the data is only available within our uh function that we know is going to be triggered to run when our data is retrieved from the background, that hasn't really changed.

[00:05:42]
We still ultimately only get access to this data within this display function. Because technically, even though, and I'll adjust this in a second, but even though our cute puppy uh string is added to a regular JavaScript object in our synchronous environment, we can't actually use that data until, well, actually, in reality, that cute puppy value is not added and not uh displayed until, well. Something's going to have to have happened in global.

[00:06:13]
We're going to have to have finished doing some synchronous stuff in global, so we'll come back to it in a second, Tenzin, cos it's going to be showing up in a moment. Chris, do you want to similarly. The example shows those objects being created in a global context, but you can do this in a temporary execution context as well, and those objects have a life outside because something else creates them, right?

[00:06:43]
Uh, why do they persist? Well, so if you define this in a local context, why would they persist? Well, we saw yesterday the heap, meaning any object that is defined uh is technically stored as a reference to its underlying position. Therefore, even if we lose the name of it in JavaScript, the object is still going to remain in that heap of objects. As long as the web browser references it, and that comes back to Joe's point that actually references to stuff in JavaScript, made not even from within JavaScript, but by the web browser, persist the existence of, for example, the promise object, even if it were actually defined inside a function call that upon exiting, you're like, well wait.

[00:07:28]
Do I still get access to it? Well, I don't need it in JavaScript, cos the only thing that can actually use it is going to be the function that was assigned to it, and that's only triggered by the web browser. So the web browser is the thing that persists the reference to the data. Great questions. Does that also start to help, Joe, with yours? Yep, great, great framing. So, let's see what it says.

[00:07:54]
Our ES6 solution and onwards is promises. Special objects built into JavaScript that get ret, I mean, you can also see, this was a very cool. Jars of the hard parts I first gave um before ES6, actually, when it came along, my goodness, my async hard parts had to add, you know, a whole piece. Um, you'll see in OOP. Uh, we had to add the whole class syntactic sugar, we'll see, and now even more features.

[00:08:24]
But a lot of change in that period has become very established. These are really great additions that are now pretty standard, but, uh, have not, we haven't had the same number of new additions in the last few years. A lot of the stuff has remained the same. ES6 solutions, I sort of see it's funny to say ES6 when it's now 10 years old, but it has become the standard. And that is promises. Special objects built into JavaScript that get returned immediately when we make a call, when we run a web browser feature using something like fetch, that's set up to return a promise.

[00:08:55]
Some of these web browser features are not set up to return a promise, like our setTimeout does not. Promises act as a placeholder for that data that we expect to get back from the background web browser features work, stored in that hidden property result. Hopefully it's going to say, and our then method. Is going to enable us to attach functionality code that's going to run on the completion of the background work and the filling in of that result property.

[00:09:21]
Any code function you wanna run on retrieval from internet data must be also saved on the promised object using the then method that stores them on this fulfill results, or fulfill reactions, sorry, fulfill uh what did I write results there? Yeah, fulfill reactions, uh, that we can, and this is a hidden property. Defined by the spec, meaning I used to refer to it as the unfulfilled list of arrays, you can really call it, you know, technically, it's not explicitly available to us, so we can just call it, I don't know, functions that will run.

[00:09:49]
Uh, the spec technically calls it fulfill reaction, actually it technically calls it promise fulfill reactions, but we know it's the list of functions that will run. Promise objects automatically trigger the attached function to run with its input being the returned, the retrieved result data. Okay. Nobody raised, by the way, which I er know you're all wondering, because I know you're all curious about this.

[00:10:23]
Well, we've just add a display back onto our call stack. What happened to our queues? Well, it turns out that there might be a little bit more to the queueing method, mechanism than we revealed so far. We saw one queue, our task queue, our callback queue. But what if there were a, well, we'll see, we're going to need to see my most complex code today. We have three function definitions, display, print hello, and a block for 300 milliseconds.

[00:10:48]
We're then going to call setTimeout, we're going to call our two-pronged fetch. Uh, we're going to call our block for 300 milliseconds, and we're going to see how this code executes. Once we've done this, we are done with our async. Well, no, we're going to add how to abort a promise, I think. I think we'll have time. Uh, and then we are onto OOP.