Transcript from the "Black-Boxing and the Debugger API" Lesson
>> Jon Kuperman: One thing I wanted to mention, and we all get into this with the example is as you're looking at call stacks, it's gonna be very, very common, especially in production apps to see a bunch of libraries that you're using that aren't your code in the call stack.
[00:00:16] So jQuery, Lodash, React, something like that. And chances are that the bug that you're trying to find are not in those libraries, chances are it's in your application logic. So one thing that you can do and you'll see this in your example as you can what's called black boxing scripts and a blackbox of script is essentially to say, for all things DevTools like, this is likely not where my problem is.
[00:00:39] I really don't want you to clutter my screen with this stuff. So, you can right-click on any script and you can blackbox it. I'm not gonna do that with debugging.js, cuz that's my application. But if you have reactor, underscore or any of those things showing up, you can go ahead and blackbox them and it'll do a couple of things.
[00:00:56] One, it'll gray them out on here. So you don't have to stare at them when you're looking at your stack trace, you can only see what your application did. And two, when you're stepping into functions, it won't bother stepping into bootstrap that jazz things like that. So that's really great as you'll notice when you start messing with production apps or it's like you, there's like jQuery is an incredibly complex library right.
[00:01:19] And so like you don't wanna be like in some anonymous function that's like the trigger method or that I mean, like some scope. You don't really want to mess with that. So just black box jQuery and again, on your way. The blackboxes persist based on your domain. So, jQuery stay blackbox on local host or something like that.
[00:01:39] How would you go about effectively inserting breakpoints and debugging those breakpoints when your page or app, or what have you that you're working with crashes almost immediately after loading in the file that you would be wanting to insert the breakpoint into in the first place?
>> Jon Kuperman: So I mean, like a little bit depends on why it is crashing.
[00:02:01] If you set a breakpoint in the first line in the first code function like I have done here, it will break before that line is executed. So at this point where I'm breaking the only thing that it is been past is executing full, nothing else, no memories has been used yet.
[00:02:40] So you might have to like read, what get coded first what is like the first thing that happen and put the breakpoint there and then I guess tread very carefully from there like you know
>> Speaker 2: So, you can only insert those breakpoint within your browser though not in your Yeah, sorry.
>> Jon Kuperman: Yeah, thank you so much. [CROSSTALK] Well, if you're working like a no, no, you can, you can. Sorry, I totally skipped on this. So, I'm gonna play this through, I'm gonna remove this breakpoint here. Yeah, so this is like a API for the browsers. I can go into debugging2.js.
[00:03:11] This is just my text editor and I can throw a debugger line here. So, that's debugger with a semicolon. I'm really sorry I skipped over that. That's a really great tool. So I have debugger here and now I'll go back, and I'll refresh it with no breakpoints and it still knows to break on debugging of line once I say yes.
[00:03:28] So if you are not able to add the breakpoint, cuz you're not able to load the app in the first place use the debugger there and also add a lint rule to make sure your debuggers don't get shipped to production. I would recommend doing, cuz that's no fun for anybody.
[00:03:42] It's even worse than a console log, cuz it's actually takes control of their screen. So yeah, the debugger API is really great.