Editing breakpoints in Chrome devtools

[00:00] Pretty much every web developer is at least somewhat familiar with the DevTools in Google Chrome, but there's a couple of things that I think a lot of people sometimes aren't aware of, that can really come in handy when you're trying to track down a large bug.

[00:16] In this basic application, I'm just calling the GitHub API to fetch my repos. When we get those back, I'm going to set those to a variable called "repos" on the rootScope, and then here, in our markup, we just have a list that's going to loop over those and spit out repo.title.

[00:38] As you can see over here, we are not getting anything in that list. Obviously, one way to debug that is to put a breakpoint here, rerun it, and then we can step through here and see...Let's make this a little bigger. We can see that result.data is an array here.

[00:59] In our array are these big, long objects with lots of properties. Stepping through this could be tedious. One thing that's probably my favorite little trick to do is to actually edit the breakpoint, which is going to give us the opportunity to write an expression that will only pause execution if this expression returns true.

[01:30] You can put things like you can check for a certain value in the data and only stop on that value. What it's also really nice for is actually logging things out to the console without modifying your actual code.

[01:46] We can actually say, "console.log result.data." We'll just grab the first one, the first object in that array. We'll spit out the title. We forgot a dot there. We'll spit out the title there. We can now rerun this. We see there's no...

[02:11] Title is undefined, so we know that there's something actually wrong with what we're trying to get out of the data. Our problem doesn't lie elsewhere in the markup or whatever. It's actually missing from the data.

[02:24] What I actually know to be the case here is that what is actually the property we are looking for is name. If we modify that, rerun this, we can see that we do get a name spit out here.

[02:37] This is super-handy, especially on larger projects. You may have a large and complex build process, or you're debugging various parts. You don't want to have to keep going back and changing the code, rebuilding, go back, rerun, that sort of thing, just to get some useful output.

[02:53] You can actually just edit the breakpoint and put that console.log statement in there. The reason this works without actually halting execution is that console.log doesn't return anything. It's going to return undefined, which DevTools is going to interpret as something that it doesn't actually need to stop for.

[03:15] If we actually remove that and go back here, we will correct our markup so that we are using the name property. Go rerun that. We can see that this is actually working again.

[03:29] One other thing I wanted to show is that when you have a breakpoint, you can also just disable it. You can see it grays it out. It unchecks it here, in the list of breakpoints, as well. This can be useful when you are in those situations where you're really in the weeds.

[03:49] You're looking for a deep, buried bug. You may have four or five breakpoints at various parts in the app. You need to turn some on or off as you try to narrow down that problem.

[04:02] The other way to disable like this is there's this global disable. If we were actually to have multiple breakpoints in our code here, we can just disable all of them with this button here or reactivate all of them.

[04:17] Then, again, you can individually control those that way. These can be really helpful. Even though it's super-simple, it can make those really tough debugging sessions a lot easier.