This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "Challenge 2 Solution" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Jon Kuperman: I think just from, however many people slamming the API thatwe ran out of reads from GitHub. So I'll probably pick a different example for next time I do the workshop. Sorry about that, if anybody was getting, like, whatever, 400s that we exceeded that. So, but basically you could take different approaches.
[00:00:25] One approach that I had kind of covered before, before if you didn't know what JavaScript was coming down, is that you could go in the Elements tab and you could find this list here basically, this repositories list. And then you could say give me a breakpoint whenever you do a subtree modification.
[00:00:43] So then you can go back up here and type and it'll go ahead and stop for you and it'll say here I am this script is black-boxed in the debugger. So I think, just to back up, because this was like the main problem people were having, I think that The black-boxing seems to only work when you're in stepping mode.
[00:01:03] If you have these like dom breakpoints set, it seems to ignore the black-boxing. It's a little ironic that it's like, this won't show up, and then it shows up. So if we just keep kind of stepping through, that might take a while. But we get to this like empty current list, is basically where we get to.
[00:01:22] And all I did was I just kept stepping over jQuery functions til I was out of jQuery. So this is like one way that you could see what's being called. Another way that you could have done it is just looking at like maybe the network tab, and seeing what JavaScript is coming down, and opening one of those.
[00:01:40] Or you could command P from the sources tab and just see what .JS files you had available and add some break points. So just to kinda like show, I'm gonna go ahead down to these break points here, and I'm gonna remove the one that I have and just play it through.
[00:01:54] So like another thing you could have just done is Command+P see what JS there is. We don't want these library files, you could find this one and just start adding some breakpoints to see if this is getting executed. Either way any approach you take you end up on debugging.js.
[00:02:10] And you've just got like something's going on here. One thing that is kind of hard to get your head around is you can only put these breakpoints on executable lines, so not declarations. This is something I always struggle with, so you can't put a breakpoint on this line here, like this success.
[00:02:27] Which seems like really counter intuitive because that's where you want to put the line. So you have to do it on something executable like line ten where you're actually executing something. So one thing you could have done, there's a couple of parts when I saw people doing was you put a breakpoint on the error callback, and on the success callback.
[00:02:45] We can remove this one and then you can kind of play it through. Oops, still got one here. And so then we see we get into error. And then you can start tons different approaches here. One that I might recommend is to be like, okay so when you're in error, the only thing you have locally scoped here is data.
[00:03:04] So you can kinda take a peek at what's data. So I'll edit this watch thing, add data as an object. And then you can kinda look through all this stuff, right. And you see, what's this response text. So you could either slide this over to make it bigger, or you can change data to data.Responsetext.
[00:03:25] And we get this not found, because we all hit the API too many times. But either way what was going on before the API had stopped working was that we were at, I think we're just at a bad URL for it, and then you can kind of step through.
[00:03:42] Sorry that they example broke. You can kind of step through maybe black box, low dash as well. And then the other thing that was going on, which I can't demonstrate right now, is that when we were getting into insert HTML, we were inserting repo.title which does not exist.
[00:04:02] So if you were to break here and examine repo I think it's called repo.name or something like that. So yeah, again sorry that GitHub stopped taking our requests, this is a bigger class than I'm used to teaching. But hopefully, at least through the examples that we did together, we were able to start getting comfortable, yeah?
[00:04:21]
>> Speaker 2: Can you talk about pausing on subtree modifications and what's that actually doing?
>> Jon Kuperman: Yeah, definitely.
>> Speaker 2: I think I kind of know but I'm a little confused as to how that links to the actual JavaScript file that's written.
>> Jon Kuperman: Yeah absolutely. So it's basically, one of the cool things about this being, Chrome being your debugger, is it's it is also the browser that is in charge of rendering stuff.
[00:04:40] And so basically what you're able to do is when you say subtree modification or attribute change or whatever, you're telling Chrome when you go to repaint this area, will you tell me why you're doing that? And so basically what you would notice from the way that we had it before, so let me remove these breakpoints and put this one back.
[00:05:01] So this is the subtree modification that I had. And you go to type something as it, where am I at come on I lost that one. Let me go ahead, and it is selected here. Okay so it's like why did you go to repaint that list and it's like I went because this append child is getting called with this element.
[00:05:22] Very specifically this is the line of jQuery that is in charge of re-rendering that area of the screen.
>> Speaker 2: So that's why it stopped there.
>> Jon Kuperman: Yeah, so it's the actual line, the last line of JavaScript that executes before it actually makes a visual change to the screen.
[00:05:37] So this is where the black-boxing comes in, though, is because if you're using any DOM libraries or you're using reactors, using jQuery or anything like that, you're not gonna get your change first, right? Cuz it's like, you call li append, and then it goes into jQuery's append or whatever.
[00:05:52] So just something that maybe you can keep in mind is that it's usually not your application code that causes the, unless you're just doing a pure Vanilla JavaScript app. But that's why it stops there. Did you have one, too?
>> Speaker 3: Are there any specific rules for the tool tip method of looking at the contents of an object.
[00:06:12] Like when you're hovering over, for example when we were in debugger. We could hover over in the repository or debugging.JS.
>> Jon Kuperman: Yep.
>> Speaker 3: We could hover over a given function and look at the object that was being passed in as the argument. But at least in my personal experience, sort of trying to fuzzily work with these particular tool-tips sometimes they work and sometimes they don't.
[00:06:41]
>> Jon Kuperman: Yeah. So they're not, I mean yeah. Ultimately you just want to add stuff like data to your watch column. However in smaller examples, it can be really nice. If all data contained was an array of numbers, it can be really nice to just like pause there and just, a time saver a little bit.
[00:07:04] But when you work with anything substantial, the data response object from a jQuery AJAX call is enormous. Yeah, it's not good. It's not going to be super useful. Once in a while the tooltip is enough, and that's I need and it kind of help save some time. But, yeah, I think it's just a little helper maybe.
[00:07:24]
>> Speaker 4: One question from on line from Richie is, is the watch but can you alter values within the watch panel or is it just for watching?
>> Jon Kuperman: Yes, so watching you can't change the values but you can take them. So like data response text is here and we're paused.
[00:07:41] And so you can take them into the console and type data.responsetext and here we go, and now you could do something like that. So you can drag them into the console and change them that way.
>> Jon Kuperman: Cool, yeah, so step through debugging's really powerful. My biggest advice is just play with it.
[00:08:03] It's such an intimidating UI, but it's really harmless, and it's really helpful for better understanding apps. And whenever I start a new job, I use the dev tools and particularly step through debugging a lot just like understand, how' is it working. One other cool thing which can be kind of a nightmare.
[00:08:19] I hadn't talked about these so you got these two handy things, deactivate all break points. And this is great when you kind of get into a nest of like you've got 13 things and you're like, I just want it to resume execution. You can just temporarily turn them all off.
[00:08:33] You can also pause on any single JavaScript exception. So basically, it depends totally on your app, but this is again, any time any JavaScript errors anything throws at any point in any library or whatever. So you can just have no breakpoint set pause on all JavaScript exceptions. And run your production app and see, is there stuff that's, because a lot of times stuff gets swallowed.
[00:08:58] Just cuz you throw an error doesn't mean you catch it and handle it. And that's true with all libraries. So it can be kind of cool to turn on pause on all exceptions and click around on your production app and see All the errors that are being generated.
[00:09:10] If there are, not saying that you guys write errors. But it can be kind of cool, with bigger apps you're going to get a lot of exceptions, right? Because a lot of libraries throw and catch exceptions, even when everything's working just fine. But, again, it can be a cool way to learn how your app works.
[00:09:24] Cool, so I'm gonna