Check out a free preview of the full Rethinking Asynchronous JavaScript course

The "Exercise 1" Lesson is part of the full, Rethinking Asynchronous JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

The code in exercise 1 will be reimplemented throughout the next seven exercises. Each time you will be using a different async pattern. In this exercise, you will write async flow-control code while only using callbacks.


Transcript from the "Exercise 1" Lesson

>> [MUSIC]

>> Kyle: So we're gonna do Exercise 1 okay. Now let me orient you to Exercise 1 and it's really important you get this orientation solid right now. Because we are going to revisit this same exercise all the way through seven, one, two, three, four, five, six, seven is the exact same problem domain.

Revisited in different asynchronous patterns so starting out with Exercise 1. Let's open up the Read Me in the ex1.js. Let's try to get more familiar with what this exercise is asking us to do. And honestly what it's asking us to do is I've attempted to articulate a pretty common pattern that we run into especially in the user interface of our systems.

What you're going to be asked to do is coordinate the responses to a set of fake AJAX calls. Fake AJAX calls cuz I don't want you to worry about setting up your own servers or any of the stuff so it's gonna pretend to do AJAX. And I've got random delays in there such that every time you run your program you're gonna get different behavior out of it.

Just like you would in the real world, okay? But these are fake AJAX they're not actually making network calls but it actually doesn't matter to us whether it's fake. What matters to us is that we want to pretend as if we're making calls and respond to the sequence of responses in a same way.

And the way we want to respond to that is we're going to request all three of them at the same time aka in parallel. We know we really should use the term concurrent but in parallel we want to make the same three responses at the same time, all right, same through request, at the same time.

Now, when we get a response back from file1 we want to print it right away. In fact, if we get file1 and file2 back, but file3 is still waiting, we want to print file1 and file2 right away. We want to render them as soon as possible, why? User perception of performance.

If we waited until all through, we were back before we printed them, the user is going to feel like the system is slower. But if we progressively run or whatever we have they're going to feel like it's faster that's a really important component of experiences user perception. Even if it takes the same amount of time the perception is important but one additional wrinkle, which is I want to make sure that those files print in the correct order.

So if I file2 comes back right away and file1 is still pending, don't print file2 yet. Wait until file1 gets there, and then print both of them. So what we're wanting to do is render ASAP but in the proper order. You see, there's a little bit of a twist here and that's intentional and that's a generalized statement of a pretty common pattern in user interface design.

Doing multiple things in parallel, waiting for them to come back, coordinating their responses, responding as soon as possible but making sure things happen in a same order. That's what this exercise calls for you to do. So let me orient you to ex1.js. You notice I have my fake AJAX, it's mapping from URL like file one to some contents and I've got some random delay in there.

I've got an output utility which is a convenient wrapper on the console along for you to use. Here's my getFile function it makes that fake AJAX call and this is the part where you need to start figuring out some code because it's pretty easy to call getFile three times in parallel.

I gave you that for free but the question is not how to coordinate the requests. The question is, how do I properly coordinate the responses and here is some hints for you. You're gonna have responses coming back, because the randomized threads you can have them come back in any particular order.

Some of them might come back too early. Which means we're going to need to have something hold onto some state for a while. You need some sort of global variable or object or array or something to hold on the responses in case you're not ready to print them.

And you need to figure out of all all these callbacks sharing over that or coordinating over that shared state and figuring out when it's okay to print something and only printing it once. All right, so we're going to take about I said five, we'll take ten minutes because I wanna make sure everybody plays around with this.

We'll take the ten minutes and then we are gonna take an afternoon break after the ten minutes, so we will come back. Talk through the solution and then that will be the time that we take our afternoon break. But I want you to play around with the pain of callbacks if you will by understanding just how hard it is to do what should be sort of a simple use case.

It's actually pretty difficult when you have to manage all that state yourself through callbacks.

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