Check out a free preview of the full Mastering Chrome Developer Tools course:
The "Conditional & XHR Breakpoints" Lesson is part of the full, Mastering Chrome Developer Tools course featured in this preview video. Here's what you'd learn in this lesson:

Jon wraps up the debugging section by talking about conditional breakpoints and XHR breakpoints. Conditional breakpoints allow you to enter a boolean statement which will be tested before the breakpoints is executed. An XHR breakpoint will only execute a breakpoint when an XHR request contains a specified string of text.

Get Unlimited Access Now

Transcript from the "Conditional & XHR Breakpoints" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Jon Kuperman: Two other things which are really cool that I wanted to talk about are conditional breakpoints and XHR breakpoints. So these are really neat for separate tasks. The conditional breakpoints are really cool. So here's a good example, a lot of times your company will have some library, a generic library that it uses like Ajax like maybe use JQuery for Ajax right and you're loading your page and one of the Ajax calls is failing or not it's like the fourth one or something like that.

[00:00:36] So it's like if you console log in Ajax you gonna get one all the success ones are if you put a debugger in. You're going to get one every time but you really don't want it every single time you really only want to debug when a certain condition is met like it fails or or maybe you only want to log if the Ajax is going to a certain endpoint like at Twitter, the timeline and what are the people and you know something like that.

[00:01:00] So you have these two options which are really cool and you get on a little bit differently. The first one is conditional. So we can let say like I wanna stop on Ajax errors, but only if and then I can add a conditional break point. And this allows you to enter any boolean statement.

[00:01:16] So you could be only if, what? You know let me scroll over, one is equal to one or something like that. But more importantly, you could do like I only want this if like data.response code I don't know if that's a thing is equal to 403 or something like that and now you have a break point that won't stop on up all the errors it will only stop on the specific type of errors that you're looking for.

[00:01:39] So that can be really cool. This is like the equivalent of like a if else console log if you've ever done one of those.
>> Speaker 2: Yeah from online Kedar is asking do a conditional breakpoints make debugging really slow?
>> Jon Kuperman: Not necessarily, it actually makes it faster if you in a certain context, right?

[00:02:00] Because like let's say I've kind of gotten down a rabbit hole of the Ajax thing but like okay let's say we want to break on a success but only on the success that has more than ten items or something like that right. Like this hypothetical example, if you were debugging without conditional breakpoints, you would put it in the success callback.

[00:02:19] And you hit play and it would be that's not the one I want and you hit me a step over. No, but if you have the conditional set up, you're breaking less. You're only breaking when IT actually needs to. And then in a really similar vein. I'm going to take this one away.

[00:02:33] If you scroll down here, you'll see your dom break points but you also have event listener and XHR breakpoints. So these are kind of cool. Basically you can, this is one I still have from working at Twitter. I only want you to break on a Ajax request that contains it in the string that contains the word timeline.

[00:02:53] Because like Twitter we're like Ajaxing in, people to follow and tweets and all. I don't want any of that stuff. I don't know where the code is but break for me when you hit the timeline end point or something like that. So there's another one that's really helpful.

[00:03:06] So you can do basically this is the criteria I gives you when the URL contains one and you can put anything you want like Json/ whatever. So you can put any of your own endpoints in and again like hopefully save you some time cuz you're only stopping on the exact ones that you need.

[00:03:24] I use those less often but again like a lot of the stuff I primarily use for getting to know an app like for getting acquainted with a new application.
>> Speaker 2: Another a related question if you put a debugger statement in your code within an if statement, is this essentially conditional break point?

[00:03:41]
>> Jon Kuperman: Yep definitely, it's like the equivalent of I have before done if else with console logs in them. This is like the debugger way of doing is conditional on breakpoints, but yep definitely the same thing.