This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "Conditional & XHR Breakpoints" Lesson
[00:00:00]
>> Speaker 1: Another great thing, conditional breakpoints. This is another one that I added cuz I've seen people really struggle with this before. As you abstract your code and you make reusable functions, a lot of times you'll be getting, as a hypothetical, you have an Ajax call that's failing, or something like that, or it's got some undefined.
[00:00:19] You're trying to see, like users.name, and it's like, users doesn't have a name, or something like that, where you're seeing this error. So you're like, I wanna put a breakpoint right where I call users.name to see what users does have, right? But maybe that function isn't just called once.
[00:00:33] Maybe you call it a thousand times in your application. Let's say it's an Ajax wrapper, right? So you have this little helper function that does all of your Ajax calls. And you only want it to stop when you're doing the user Ajax call, right? So you can think of concepts where you're like, I only want you to stop when a condition is met.
[00:00:49] They have this really cool thing called conditional breakpoints. So you can right-click on a line number, and you can add a conditional breakpoint. And now you can, if really well written, it says, the breakpoint on Line 2 will only stop if this expression is true. So we could do something like foo === foo, right?
[00:01:05] And now we have a yellow breakpoint here. So if we refresh, we know foo = foo, so it'll stop there like normal. But if we go back to our code and change this to bar, so we're calling it with bar now, and then refresh, you'll see that it's not stopping here anymore.
[00:01:20] It just reloads the whole page. So those are mostly useful in situations. You definitely will run into this. You'll put a breakpoint on a line, and then you'll refresh the page, and it's like no, not that. You're hitting play, play, play, and it just keeps calling the same line.
[00:01:34] And you're like, I only want you to stop when a condition is met. Conditional breakpoints are great for that. In a similar vein, we have XHR breakpoints. So this is another really cool one, where you're not sure where. Again, this goes back into the DOM breakpoints. So you're not sure where the code is, right, but you know what is going wrong, right?
[00:01:53] So if you have an infinite scrolling website that pulls for updates and you know there's something wrong with that update pull, but you don't really know where that lives, right, cuz you're new to the code base or whatever. You can go down here into these XHR breakpoints and then you can quite simply say, whenever we do a request for a URL, stop if the URL contains a string.
[00:02:14] So I've got one here that's calling this api a point over and over and over again. So if I were to put, okay, stop if you do something that calls api, we can see that it stops right here. And then we can see that we've got, sorry, my thought is a little split.
[00:02:30] So we did stop when you see a fetch happen for the word api. It hit it right away. We stopped, right? But we'll see over here in the call stack, there's VM and stuff, right? This isn't our file. This isn't what we wanna be debugging, right? This is like some, I don't know, some Chrome code, or something like that.
[00:02:46] The fetch implementation is probably what it is. But we can look in the call stack and what we wanna do is find your files, right? You wanna find the stuff that you're working on. So we can see our file here. So we can step through the call stack like this and we can find the exact line of code.
[00:02:59] This example is really contrived cuz we only have one JavaScript file. But you can imagine a really big app, where you're like, I have no idea where the update settings call happens. I'm sure it has the word settings in it somewhere. So you can set this conditional breakpoint, and magically, it'll show you what line of code is responsible for that.
[00:03:15] Unlike the step through debugger, the call stack is time travelling. So you can go down into here and you can see, and then you can go back up into here, and you can go back down into here. So you can step back or forth through the whole call stack.
[00:03:27] It persists all of that. And while you're in the call stack, you can use watch, right? So if we had a local variable in here, we could add a watch for it, and it wouldn't exist outside, but it would exist inside, that kind of concept. So you can start combining these things.
[00:03:40] You set an XHR breakpoint. It gets you in there. You can see the whole call stack. Start stepping through the call stack, watching variables. You can really see what's going on with your code. I don't like being prescriptive. A lot of people are like, you should never use console log.
[00:03:54] You should use debuggers. I still think console logging is an awesome way of debugging your JavaScript code. That's the cool thing about websites, just refresh and it's there. But when you're starting to get really frustrated and you've got a bunch of different console logs and they're firing all over the place and things like that, the step through debugger, it's just such a great tool that seriously take a minute and fully understand how your code's working, what it has access to, all those kinda things.