Check out a free preview of the full Asynchronous Programming in JavaScript (with Rx.js Observables) course

The "Debugging Async" Lesson is part of the full, Asynchronous Programming in JavaScript (with Rx.js Observables) course featured in this preview video. Here's what you'd learn in this lesson:

Jafar spends a few minutes talking about debugging. When working with asynchronous code, step-into and step-over statements are not always as effective. Jafar suggests using the debugger directive and setting breakpoints.


Transcript from the "Debugging Async" Lesson

>> [MUSIC]

>> Off Camera 1: If you go back up, let's say in our JSON we had one interesting moments that had two type middles, let's say, that wasn't actually unique and we just thought it was, what would happen in our code here?
>> Jafar Husain: Good question. Good question. Well, this case, nothing, because we're running it through zip.

So if one element, one array has two elements, and the other array has one element, zip just stop zipping up. Just like when the zipper doesn't have a tooth on one side, right? You're like, struggling with that zipper. It's because, it stops as soon as there isn't an element on both sides.

>> Jafar Husain: Yeah. That may or may not be a bug or what you want but that's how it'll behave.. Yeah?
>> Off Camera 2: There's a question about testing, when building up these long chains of commands, what is the best strategy to debug them?
>> Jafar Husain: So, that to me, is a really important question, right.

It is not that you cannot debug these programs. It's that you can't debug them in the way that you're used to, right. The way, when you're used to debugging imperative programs, which do something, and then they do something else, and then they do something else. Sure enough, the debugging tools we have are built to accommodate that.

Step in, step over, so on and so forth. But let's debug this, let's actually see if we can debug this program. It is unquestionable. The first thing I wanna level with you. It's harder to debug this. There's no two ways about it it's easier if you just have 15 lines of code and you just wanna step over them one on another.

What we're doing here though, is one of the reasons it's so much harder to debug this code, is cuz we're taking a large amount of code, that we would have written in line, and we're making it somebody else's problem and putting it into a library. That's a good problem to have.

Right, now all of a sudden the code you would have had to write is now being written by somebody else. And so often, if you're trying to step through your code kind of jumping around, right. But understand, remember why that's happening, it's because you're taking on an enormous amount of code and somebody else is now writing it for you.

So, yes, it is harder because all the sudden somebody else is calling your code, right. That's what asynchronous program is all about. You're handing your code to somebody else and trusting them to call it. Well, that makes it harder to follow the control flow, right? But that, you get amazing things for being able to do asynchronous programs, right?

We get more concurrency, more efficient things, more reactive programs that respond to user interfaces. So let's not forget why we get that. But how do we debug a program like this? Well instead of step over, step over, step over, it's set break point, play, set break point, play.

So you figure out where the next point is in the code, or your code is, right? Here, let's actually try this, you can see what I mean, I'll do it in Chrome, cuz I'm a little more familiar with the the chrome debugger. I'm sure you can do that with Firefox, I'm just not Firefox proficient, so if you are Firefox proficient don't let that stop you from using Firefox, a wonderful browse.

I'm gonna zoom up here to maybe the last place we had some working code.
>> Off Camera 3: Yeah. Firefox is more finicky about when it catches the debugger. Like you have to, Chrome always catches it no matter what. But Firefox, you kinda have to have the debugger open.
>> Jafar Husain: Opt into it, I see.

>> Off Camera 3: Like that or it will [INAUDIBLE].
>> Jafar Husain: There we go. So we got a spot in the debugger, right. And so, you can always put a break point or a debugger semi colon statement inside of your own function that you pass to map. And so, this gives me the opportunity to examine variables, right?

And like is movieList what I expect it is? I know it's not working right now, but it usually does. Sorry, in this resolution I'm not sure if the pop ups happening somewhere else or.
>> Jafar Husain: You can always explicitly add a watch expression. So I can look at the video, right, that's being passed in the map.

I don't know if that's big enough.
>> Jafar Husain: Does that makes sense? So if I wanted to step through multiple functions, right, I would go through, add another break point again, it's a bad example, and then just play to the next the next function that I own, right. So if I've got another function it's past a filter or reduce or a zip, I can put a breakpoint in there and then play instead of trying to step over and step into there.

Does that make sense? So that just, you can still examine every single line of code that you write with a debugger, and check the variable values. It's just that you need to use the play, the breakpoint and play strategy, rather than the step over and step in strategy.

And so that's how you debug this type of code. Yeah?
>> Off Camera 4: Sometimes I've notice I can't set a breakpoint inside the asynchronous section until I hit it above. Is that a case or do [CROSSTALK].
>> Jafar Husain: I mean, debuggers have bugs. I've run into that problem. I have run into that problem myself.

Sometimes I can't set a breakpoint and then something weird happens and I can. Sometimes it has to do with optimizations that the actual JavaScript interpreter is doing and so, for example, I think the reason why it's not displaying, I'm not sure why it's not displaying, to me this is a bug.

It should add it, but if we have to watch we should be able to see it. Maybe this, no interesting, not available. Yeah well, and you know what I think is going on here, even though you should be able to see a movie list, you can't. And because Chrome is actually doing a lot of optimization, it's saying, hey you're not using movie list in this function and it's actually not making it available.

So if you run into that problem, there's a very easy solution, which is you can just throw in a console log of movie list inside of the function to force Chrome to make it available inside that function. So then you can then you can add a watch to it.

>> Speaker 6: What about unit testing?
>> Jafar Husain: What about unit testing. Well the wonderful thing about this, at least we haven't talked about any about asynchronous programming at all yet, right. We've just talked about loop less programming, this entire day has been a, how to program without loops. Right, and so unit testing honestly, it's no difference, right?

When you make a unit test you write a function and then you wanna confirm that function outputs the right result. If inside of your function you happen to use this style of coding versus loops, that doesn't make it any more or less testable. Right, you're still testing that that function returns the right result.

So testing is totally orthogonal to this. Now it's asynchronous testing is a challenge, right, and well we can talk about that later on I would make it to be async stuff. But most framework support async testing, the point is you basically have to asynchronously signal when the test is failing or succeeding.

So if you use Mocha, almost every JavaScript framework supports some form of asynchronous testing.

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