JavaScript: The Hard Parts JavaScript: The Hard Parts

Asynchronous Q&A and Pair Programming

This course has been updated! We now recommend you take the JavaScript: The Hard Parts, v2 course.

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

Will takes questions from students before setting them off on pair programming challenges.

Get Unlimited Access Now

Transcript from the "Asynchronous Q&A and Pair Programming" Lesson

>> Will Sentance: Let's see any clarifications. Griffin has one or two is good. Griffin, it would take going into a online clarification. Griffin, you wanna go?
>> Griffin: Is there a way to bypass the event loop? Like manually coding, come back in at this time. No?
>> Will Sentance: This is a very strict, because if you could, how unpredictable would that code be?

[00:00:19] We could randomly say [SOUND] come second up. Now there is ways of setting ordering. So what you people often do is, you don't print hello, you don't console hello inside this function. You know what you do? You speak off to another inside of another one, so you can order things by in the call back you past, in there making another reference to a web browser API, cuz you therefore know this one must complete before that next one is made.

[00:00:48] Because it's being made inside the call back and that is what creates, who knows what that creates? That the famous call back hell. That's the notion of, when you hear of call back hell, what it is is saying, I need to delay my next call back until I know I've successfully completed the previous API interaction.

[00:01:07] In this case, timer. But it could be for data from an API, from an outside API. I need to complete that one and get that function running. And then inside that function make the next request. Because we've gotta wait on that first data before we can make the next one to store into a database, for example.

[00:01:25] So you make call back, and then another request inside that call back, another request inside that call back. All using the fact that when you insert your additional request, your next API interaction inside the function that got passed to the first one, first API interaction, you know that first API will have done, for Print Hello to be running it must have completed.

[00:01:49] And therefore you can write your next request inside here and you know it will be coming after. So it's a way of ordering stuff. So that sort of answers the question in the sense that that's what people do. But you're certainly not able to just go, now let me de-queue and just go.

[00:02:04] I can't, timing is a weird thing in any environment. It's hard to, this the way we handle timing in JavaScript, and it's by setting constraints on ourselves like this, otherwise the unpredictability of when our functions will be calling, where our functions would be evaluating to. Suppose we through Print Hello on while block for one second is on top, that means Print Hello is gonna evaluate into block for one second when it completes.

>> Will Sentance: You get all sorts of interesting rates, conditions, that means I'm waiting for some data that's not been ready yet. All this stuff is protected for us by a very strict set of rules. For now, we're gonna do another block of pairing. After this we're gonna look at one final version, for now, of pur web browser API.

[00:02:54] If you've seen timer, but there is a whole bunch of other ones, including the ones that do the ATTP requests. You’re going to start to see those in the challenges in a moment, and we’re gonna look through those after the challenges. All right folks, back to your pairing, and we’ll go and look at the challenges