Callback Hell & Async Exercises

[00:00:00]
>> Will Sentance: Let's briefly analyze this approach. And we'll see this now after pair programming, it's sort of a newer approach to this model. Problems of the approach. A lot of the time, these background features, the function that's then automatically called, the background feature gets some data. So for example, if the background feature's speaking over the network, to get some new data in, well then, where's that data gonna show up?

[00:00:31]
That data shows up as the input, automatically inserted into the running of that printHello function. That's pretty amazing. But the problem with that is that means that data is only available inside the execution context of that printHello function. So if you've gone off to Twitter, grabbed a bunch of data, the function that's gonna run automatically own the completion of this being to Twitter in the background, the function's gonna run automatically.

[00:01:00]
It's gonna have its input be that data from Twitter. You could only use that data inside that function, because we don't get to run this function. Therefore we can't have it return anything out. Because we can't assign the return value of it anywhere. So instead, that data's all gonna be used inside of here.

[00:01:18]
That's pretty rough. And that's what created something known as callback hell, where we are doing all of our work on that data from Twitter, inside of one function. As we do function, inside a function, inside a function. That's pretty rough, I see that. But I'm gonna show you that, in terms of what we're actually doing later on in a newer version, under the hood, it's not changing much.

[00:01:41]
But in terms of readability, it makes it much better. I don't even know if I fully agree with this. Maybe it feels a little odd to think of parting a function into another function only for it to run much later. Look, we pass in printHello. Only for it to run automatically, much later.

[00:01:56]
But as long as you live in a language where you're going to use background features outside of the language, you're kinda inevitably doing that, right? You can't, there's no real way around it. You're gonna rely on that background, the web browser itself with JavaScript to bring that function back in for you and run it when it knows the background work is done.

[00:02:16]
Benefits, I'll say of this style, super explicit, super click. Once you know how it's actually working, it's fairly kind of simple, fairly. [LAUGH] Well, you wait till you see the next version. At least here, it's fairly direct. I take in a function, I attach it to the background feature, it gets put in the queue when the background feature is done.

[00:02:39]
Even if it's a 0 millisecond feature, it goes in the background. Yeah, to be clear, Brayden, this is why even though it's a 0 millisecond timer, as long as it's being thrown out the printHello function, it's gotta queue up before it's allowed back in. The other, I think, problem with this approach is that for error handling, it's not as clean.

[00:02:59]
You wait til you see the promise approach. Its error handling is super nice. We will see that, people, though, after some pair programming. Gonna see a speed dial/async, you know how to pan out, and get pair programming.