JavaScript: The Hard Parts XMLHttpRequest Q&A
This course has been updated! We now recommend you take the JavaScript: The Hard Parts, v2 course.
Transcript from the "XMLHttpRequest Q&A" Lesson
[00:00:00]
>> Will: Let's have questions and see if our online audience have any interesting questions as well. Nathan, if the display function returned to function then you could save the data via Lexical scope. I mean, you can just by returning out that data. Okay, I see the issue. What our friend Nathan is asking is, hold on, we're able to console log our data at this point, but how do I return?
[00:00:33] Because display can't evaluate, display doesn't get to say, assign the result of display to a variable. That's a bit of an issue. That's a bit of an issue? Do you see what we've got there? Our display is being called, but we don't get to see, assign its result, its return value anywhere.
[00:00:55] So how do we hold onto this data?
>> Andrew: Variable?
>> Will: Well, looks like display is running in global, it is. But we're not able to assign its result, its return value anywhere. That's very frustrating. That's very frustrating, right? But why would we? Because this function is being called at the very end once everything's been done in synchronous land.
[00:01:23] So we've now entered, most of the time in our JavaScript applications, we're actually dealing in not in our original set of synchronous code, cuz we are dealing with lots of interesting interactions like this. So how do we actually save our data? Well, we usually wanna use our data in some way.
[00:01:41] The reason we want to return out data is typically to use it. Well, instead of returning it out of display to use it, instead we make a brand new request in here to maybe another place. So typically, we wanna use that data to say for example, display it on the page, or we want to store it to a database, or all of these things.
[00:02:02] So inside of this function call, we have access to the data, we can't return out. So where's our returned from display? As soon as I wrote instead of consolelogdata.post, return. Well, where's that gonna return to? Cuz display is being called and it's not storing that result anywhere. And there's no way of writing this function such that it's like, result somewhere's gonna, there's no way of doing that.
[00:02:27] So you've got a bit of a conundrum here. How do we even, well we've have access to the data inside the call to display. So what do we do? We can use the data inside here including by passing it to the call of another function. And then another function inside of there, and another function inside of there, and that of course, is known as callback hell.
[00:02:52] And it makes sense why we have to do it, right? Because we've got to use this data somehow, maybe say we do a database. But we can't return out of this function so instead, we use that data inside of this function. That's frustrating and hard. But it is where callback hell becomes challenging.
[00:03:09] Now that's all changing. We're looking underlying principles of JavaScript here. That's all changing. Increasingly now, we wrap this whole behavior in a different format. What is that different format that makes us feel less like, I'm doing this, and then inside, and then inside, and then inside, but rather more procedural step-by-step.
[00:03:28] What's that new format called? Promises, exactly. But they are doing some stuff slightly differently under the hood, I'll grant you that. But they're still the same idea that my function is going to have data passed to it from my API, my callback function. And from there, I'm going to use it in another call to another function.
[00:03:50] So it's still that same underlying principle. Promises give us an extra layer for that. But it's still this same underlying principle. All right, any more questions at this point? Otherwise, we're gonna go back to one final set of pairing before lunch. It's lunch, so we're gonna pair through lunch.
[00:04:05] Andrew?
>> Andrew: I wanna clarify why display went to the call stack before global was off it?
>> Will: So, global has finished it's execution.
>> Andrew: So it did go away.
>> Will: It went away in the sense that, global never fully goes away, it's always there, it just has no more code to execute in it.
[00:04:25] Okay, makes sense, Andrew, yeah. That's a good clarification. We've finished running all of the steps in Global, but the application's still running, Global is still always in the bottom of course app.