Promises Review

[00:00:00]
>> Will Sentance: Let's talk about the benefits and not to benefits of this approach. So, problems 99% of developers have no idea how this work under the hood, which makes debugging just this mystery thing. And on top of that, I think yeah, I said that now, on top of that I felt going to interviews.

[00:00:20]
The upside of this style is it creates something that sort of means if you don't understand how it's working, you can roughly make it kind of work. I will say about the old style where you literally pass a function in, if you understand how it's working. You're kinda done, this style, because of this appearance, the then method you kind of think you know what it's doing and it kind of work but really, I hate this name, then.

[00:00:45]
It's doing nothing, if I'm reading this code as a developer I'm like, okay, so fetching and then I'm gonna display. But of course, it's not even close, maybe we even think that kind of if we go back up the thread and do that line and then bit later, No, no, no, then should be renamed what?

[00:01:00]
I think it should be renamed this, store function to Run later, yeah, exactly. Future dated dot, store me to Run me later automatically when the background task that came out of the fetch call previously completes and the value probably gets updated. Not catchy, but it is accurate, mm-hm, so I will add one more benefit though.

[00:01:23]
So people think kind of cleaner, readable style, I will say, like pseudo synchronous, it sort of looks like you are running it right then but you really are not. You are passing in a function that is going to be also run as before, not by you, but by JavaScript.

[00:01:36]
And it's taking an input that you did not put in there, JavaScript put in that. That from the background work that high string that's gonna be auto inserted into display function when it's AutoRun, I love it. By the way, once you see that JavaScript was one sees that JavaScript is taking that function code of display, and it's running it for you by putting Print on it for you automatically.

[00:01:55]
And it's inserting the input for you automatically It's a very generous language in that sense. There is one big benefit of this design, and it's that era handling process, so, this is really nice. It turns out people, there's actually another array on this promise object behind the scenes, another hidden property.

[00:02:16]
And it's called onRjection, and it's also an array into which we can put functions. When you're interacting with the outside world especially network stuff you get errors all the time. You don't wanna run your display functions so the user on Twitter gets a lovely broadcast of the full details of the error.

[00:02:38]
Ideally wanna have a separate function that's going to run that handles that error. Maybe it logs it for you in some way, but probably just gives the user a better experience. It's doing something similar, maybe, whatever it might be, now, how can we handle that? Well, you know what?

[00:02:54]
The promise object give us this amazing feature, that means if we get an error back not the actual response object we want any error, it's not gonna Run that display function. It's not even gonna auto trigger any of your functions in unfulfilled, it's gonna trigger any functions that you stored in onRejection, how do we get functions in there?

[00:03:14]
Well, there's two ways, one would be to write future,
>> Will Sentance: Data dot, anyone know? Dot catch spot on exactly, Cate is right, dot catch, and any function we pass in there, it's going on rejection, right? The other way is to pause to then as the second argument, whatever function you want that's going to go in here to AutoRun on error, first argument, stick that function in unfulfilled.

[00:03:42]
Then we'll take the second argument, the second input and stay that function that you rejected? That's really nice, that's a really, really nice error handling approach without a doubt. Alright folks, so there we have it, we now have rules for the execution of our asynchronously delay code hold promise deferred functions.

[00:04:03]
This is what Dan was saying promise deferred functions, ones that were attached to a promise to delay them running until something happened in the background. Store them in the microtask queue and callback functions, ones that were passed in to one of these facade functions like timer, sorry, set timeout, have them go in the callback queue.

[00:04:23]
When the web browser feature otherwise there is API finishes, add that function to the coolstack. In other words, Run it when coolstack is empty and all global code is finished running, have the event newcheck this condition for us. Before we learn the code is I would Run next, prioritize functions in the microtask queue over the callback queue.

[00:04:52]
Promises web browser features, the callback and microtask queues and the event loop enable us to build non blocking applications. We do not have to wait in this single JavaScript thread, we do not have to wait here for our data to come back. No waiting on this line, fetch will not sit on this line, waiting for the data to come back, no, no, no, no.

[00:05:12]
I mean no in regular code we do, your function cool you are staying on that line till you finish it. But it is not a regular function call, it is a facade function for setting up background work. However long it takes we can't predict when our browser's features work will finish in the background.

[00:05:26]
We can't know exactly when it's gonna finish, so we can't kind of have the line of code that's gonna use that background data Run right now. We got to tell it when to run, we got to rely on JavaScript that knows when the background work is done to automatically trigger, the function to Run on that moment.

[00:05:43]
This is what allows us, people, to build these non-blocking, dynamic, fast applications. We can handle setting up a ton of stuff in the background while we race on in the foreground running our code, being responsive to users' interactions, building these dynamic applications. This is what really makes JavaScript very, very special and very usable.