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

Most of the time, JavaScript errors will be located within the application source code and not inside any included libraries. Jon demonstrates how to “blackbox” scripts, so the browser developer tools ignore them.

Get Unlimited Access Now

Transcript from the "Blackboxing" Lesson

[00:00:00]
>> Jon Kuperman: So yes, we can step through JavaScript files. We can add break points, which we saw we can do that via the debugger, or you can just do it by clicking the line number. Black-boxing scripts is really important. So once you get into real applications, we all use frameworks or libraries, right?

[00:00:15] And so what you'll often see is you're trying to figure out how you got to this error state, and you've got this call stack that'll be 300 functions long. And most of them are React internals, Redux intern. You know the bug is not there, right, the bug is in your application code.

[00:00:30] So what you can do if you ever have file names here that you're like, I'm not interested in that at all, you can right-click on any file and you can black-box the script. And blackboxing is essentially that, it's, this is not mine, this is some third-party thing. I don't need this right now, so it'll black-box it.

[00:00:46] That'll do it by the URL that you're loading, right, by the app you're loading. There's also an option if you go under the three dots here, and you go into settings, and then Black-boxing, you can add permanent black-boxes. So, you can be like I never wanna debug JQuery.js, that's not my file, I don't want you ever to stop in there.

[00:01:03] Because another thing that you'll see the call stacks will be long. But also sometimes you'll do that DOM break point that we did in the editing section, you'll be what's changing the color of this. But if you're using a library like React, it's always gonna be React that's changing the color, right?

[00:01:18] You don't really wanna see the React code, you wanna see your code, right? You wanna see where you call a set state, you don't wanna see where React actually manipulates the class list or whatever. Yeah, Steve?
>> Steve: So let's say I have React that calls jQuery and also have D3 that calls jQuery, and I black-box React, will that automatically black-box Box D3?

[00:01:41]
>> Jon Kuperman: It will not, so you'd have to black-box all of the ones that you want black-boxed. And the UI's actually really great with those kind of examples. Cuz what it'll start doing is it'll start, it would show you D3 and then it would show you this little mini thing that says we hid 20 scripts because of your black-boxes.

[00:01:58] And then it would show you whatever your other one was. So as you add, kind of more and more, but you would have to do each of them because it's all just script names to them. But again, if that's common, going to the settings in the global just makes life a lot easier, where you're like, I work with React and I work with D3 a lot.

[00:02:16] I don't ever want you to show me those in the call stacks or in the watch mode, and everything gets a lot easier. Any other questions on black boxing? Yeah, and it's also really safe, it'll always, even after you've black-boxed there's always, it'll show a black-boxed list here and you can un-black box scripts.

[00:02:35] So it's not like you lose access to things like that, it just tries to compress the call stack for you.