JavaScript: The Hard Parts, v2

Promises and Asynchronous Q&A

Will Sentance

Will Sentance

JavaScript: The Hard Parts, v2

Check out a free preview of the full JavaScript: The Hard Parts, v2 course

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

Will answers several questions from the audience regarding the returned data from the fetch function, whether functions are passed by reference or by value when passed to a web API, arguments within the function passed into the web API, what precedence objects take within the queues, and which functions go into the microtask queue and which go in the callback queue.


Transcript from the "Promises and Asynchronous Q&A" Lesson

>> Will Sentance: Braydon, go ahead Braydon.
>> Speaker 2: So if we're trying to use the data storing data from the network request, how does it if you have a line of code in the JavaScript, in the global. How does it know when it can kinda access that?
>> Will Sentance: Behind the scenes in reality, this high value is never filled in actually.

Until all global codes finish running, so we can't even get access to it at that point until we have, we only get access to it from the front. And then that way, I mean that different from the callback model, right? You only get access to from the function that we add, we also triggered because we just don't want to have a language.

Where we can go and try and get access to stuff and we don't know if it's gonna be there or not. So we don't actually fill that in behind the scenes automatically, until all global codes finish running. Okay, in practice that has a small consequence. But it's slightly different to the way I sort of showed you here where we sort of imply it gets filled in here at that moment.

But in reality it's at the very last minute, before we start going through the queues. That has no consequences in terms of. We don't run these functions until it's filled in, until we finish all the global code anyway so no consequences. Mark?
>> Speaker 2: I'm trying to think of how to phrase this properly.

>> Will Sentance: Do you want to take one sec?
>> Speaker 2: I can try. If it's a print hello when the browser has it, is a reference to global print hello. Is not print hello itself.
>> Will Sentance: Yeah, we're not taking into the web browser a copy of the function. We're just giving a reference back to in memory, this function, yeah.

>> Speaker 2: Could print hello, take into consideration by the time you hit the cost text something another parameter from global memory? Or is it must have been can.
>> Will Sentance: It will be hard to do so, because.
>> Speaker 2: Yeah.
>> Will Sentance: Hold on, who's putting the parenths on print? Hello, are we doing it, yeah.

Are we putting prints on print? Hello?
>> Speaker 2: No.
>> Will Sentance: No JavaScript's doing it. If we're not putting brands on how do we insert any arguments? We have to rely on knowing. And this is a really good point, the most making here. It means we have to know like, for example, you might answer a different way mark, hold on.

Could I have two arguments passed to me that's all about display the function that gets its first input. Data that comes back as if I could only be have that expect two arguments. Now, I've got to go and look at exactly how the feature of the web browser that this function is going to be auto triggered when the feature web browser finishes work.

How it's expecting how the web browser and the promise of disease expecting this function to be laid out. Where do I go to find the rules about that? Where am I gonna find out how the browser is expecting the function that will be auto run. When its work is done is gonna work and what inputs it's gonna take?

How do I find that out, everybody? Whether it's a website.
>> Speaker 2: MDN.
>> Will Sentance: Shutting the MDN, exactly. MDN has got a list of all these features. They don't call these facade functions. They call them API is a it stands for interface that is any functionality or often data that's not in my world, but in someone else's and I interface with it.

These are my labels by which I can interface interact with this outside world. That being said slightly related to what you're saying, Mark, though, is suppose I set timeout call inside the execution and other function. And it wanted to use some of the data from that execution context.

Well, by the time print hello runs, it runs in global, that execution context in which set timeout with set up has gone, and all its data's gone, unless the-
>> Speaker 2: Backpack.
>> Will Sentance: Backpack, exactly, print hello has a link to all its surrounding memory that could ever be used in it, pretty awesome, that's pretty amazing.

Okay, we had another one, yeah, Jason, please?
>> Speaker 2: [COUGH] Excuse me, so the example at least gives us the impression that the micro-task queue is either first in, last out, where it's used preferentially-
>> Will Sentance: Good question.
>> Speaker 2: Where you've got depending on the type of call you're gonna get a queue.

My suspicion is the micro-task is actually has its own invent loop
>> Will Sentance: Because well no, the event needs handling. Let's talk a bit about how the micro task queue words relates to what Jason's asking them. What if isn't really interesting? So it turns out with promise objects, I can just create one directly.

I don't need to have it automatically created by fetch, I can actually just say create one. If I then say resolve that, that is to say in that line of code in that moment. Have it automatically complete and have its function at that I can control that function.

We can do that with fetch. Because fetch is handling the relationship here, but if I make my own promise object, then I can have the function attached to it. I can directly myself have it stuck into the microtask queue by having the value property of that promise object updated and complete.

And automatically trigger the function to run in the microtask queue. Here's a really interesting scenario. If when I'm running the function that was in my microtask queue that was displayed, If inside of there. I create a brand new promise object that its associated function while I was inside display.

That promise object completed because I told it to directly, the associated function will be stuck into the backend of microtask queue while I'm still inside display.
>> Will Sentance: Here's a really interesting situation that can happen then. I can be filling in the back of the micro task queue with more functions while I'm still inside display.

And the event loop is interesting and how it interacts with the micro task queue is a very, very big bonus sort of. If you go to if you want to know the node hard parts, we go into some more detail. They're worried too much about this. But I am feeling if I want I'm inside display and filling in new functions behind here.

And they themselves are building a new functions. And then those are pretty new function almost recursively. I will never leave the microdose queue because the event loop will always take in and execute on the call stack. It will always go back and check the microtask before it moves on to the callback queue.

That is in distinction to the callback queue which once it enters does all the stuff in there and then moves round again. The microtask queue once it enters, if you are refilling in the back, you ain't leaving it. You get what's called starve the callback queue and in Node.

This is particularly important because you want to, you know, production application. And this is why there's some caution around around using the process next tick method. Which sticks stuff in this queue, and can recursively starve you handling your requests from your users. Valence I topic, but go watch the Node Harper's, you're interested in that, but it's an interesting nature that these are behaving slightly differently.

Just as Jason was hinting, there was one more Brayden, was it or was it Peter or Kayla? Dan, it was Dan, yeah, go ahead, Dan.
>> Speaker 2: Yeah when you may have already mentioned this, but. What items go into the microtask queue and what items go into.
>> Will Sentance: Great, great point.

Let's just be really, really clear. Any function that is attached to a promise object by one of these two prongs for stored functions. Which gives add a promise object we attach a function to it using them. Those functions all go into the micro-task you. Any function that's passed in directly to a facade function that triggers a web browser feature you see the reference that link to the function down here.

Those functions when they complete or sorry when the background task the timer completes this function callback. So we have to go into MDN and see, does our particular facade function that trigger stuff in the background? Does it take in a function? That one's going to go into the callback queue?

Or does it return out to promed a promise object and they toss to the background but doesn't throw a function down here. The associative function on the promise object, that- microtask queue. Okay, sweet.

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