Transcript from the "Promises Review" Lesson
>> 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: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: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.