
Lesson Description
The "Step Through Debugging Exercise" Lesson is part of the full, Mastering Chrome Developer Tools, v4 course featured in this preview video. Here's what you'd learn in this lesson:
Jon introduces an exercise to practice using the debugger to identify and fix bugs. Jon demonstrates how to set breakpoints, explore the call stack, and make code changes to resolve the issues. He emphasizes that while console logging is powerful, using the debugger can provide more robust information, especially in cases where console logging may be time-consuming or insufficient.
Transcript from the "Step Through Debugging Exercise" Lesson
[00:00:00]
>> Jon Kuperman: So yeah, let's move into an exercise. We'll take just a bit of time to do it, and then we'll just do it all together. Again, the point is not so much getting through the challenge, although you're more than welcome to the point is to try to get comfortable with using the debugger.
[00:00:13]
And so what I tried to do here is I tried to make a challenge that was a little bit too hard to solve with just a few console logs. Something that would be really nice to get through. So if we open up the DevTools here and we go to Console, this is the starting place, we can see that we're supposed to get this list of Pokémon rendering here.
[00:00:30]
And they're not rendering and we've got an error here. And to go through here to click through, set some breakpoints, explore a little bit, see if you can figure out what's going on. And then we'll meet back and we will go through the solutions together.
>> Jon Kuperman: All right, cool, yeah, let's go through this exercise here together.
[00:00:50]
So if you go over and view the page, we can see that there's some Console stuff wrong, some errors in the Console, and that we don't have a list of Pokémon evolutions. And again, the point here is not necessarily to get the exercise complete as much as it is to get comfortable going from these Console errors into the sources and adding some break points.
[00:01:08]
And just in a more complex bug like this one, making sure that you can kind of at least check your assumptions and identify what is working and what isn't working. So kinda go through first and click on this link from the Console. And we can see that we essentially are trying to call .species on something that doesn't exist.
[00:01:26]
So this chain is undefined. So we can kind of quickly add a break point above it and then refresh the page which will hit the break point. And we can just verify for example that chain is in fact undefined. So if we wanted to see where it was coming from or why we expected to be there.
[00:01:42]
Maybe the next thing that we can use is the call stack. So we can kinda go up the call stack and see what's getting passed in. As we would expect, evolutionData.chain is undefined. But if we dig a little bit deeper into why, we can see that evolutionData isn't actually a JavaScript object.
[00:01:58]
It's in fact, a JavaScript request response body, sorry. So it's an HTTP body with type cores and status 200 things like that. So we can go in and kind of mess with the code here and call to JSON on the fetch before we try using the data. So we can come kind of here, where we've got, are we on line 14?
[00:02:19]
So we've got this fetch here, and then we can put then block underneath it, which does response, response.json. And I think we've got one here as well where we can also add a response, response.json. So we can go ahead and refresh these, remove that break point, do a refresh, look in the Console, and now we've see we've got a different error.
[00:02:38]
Basically, we've managed to get through that one, and we've got some other one. And so here we're trying to append child on something that is undefined. So if we were to go ahead and set this break point and refresh, we could see that this evolutionSequence is actually null, undefined.
[00:02:54]
So if we scroll up a little bit, we can kind of see what we're messing with here, and that we've sort of got this evolutionSequence, which is here. It's a getElementById and the getElementById is looking for this Pokémon evolutions, which is this div that we sort of append to things.
[00:03:13]
And so the problem is, if we go here instead of break point and do a refresh, we get this here, and we can see that thisdocument.getElementById. Let me go into the Console and paste that in, is not returning anything. So if we kinda come here and we see that, basically we're trying to append child to this.
[00:03:33]
And this should be querying this, but it's not in there, and it's because we've not stuck this div into the actual DOM. You can see here we append the Pokémon div and the evolutionSequence div, sorry, and that's on line 39. And so the only bit that doesn't make it into the DOM is the need to append that list item itself.
[00:03:56]
And so the list item is the li that gets created and that needs to get appended to the Pokémon list element.
>> Jon Kuperman: And so we'll do the list element, append the list item, we can remove this breakpoint for now. And we can come back here and we should now see that we've got things created memory, appended to the DOM, and the API is working correctly.
[00:04:21]
And you get this cutesy little list of Pokémon evolutions. So again, I think there's not the focus on the specifics of the bug, but more so hopefully expanding the tool set that you have when things aren't working correctly. Instead of just console logging out the errors, taking a second, pausing, being able to go up and down the call stack, check your assumptions.
[00:04:43]
Eventually finding what things you're relying on being defined that are undefined. And from there, using your own understanding of your application to fix the business logic itself. How's everybody feeling about the debugger part of that in general? Reasonable, yeah, it gets a bit heavy. I am not on any type of mission to convince people not to console log, I think console logging is an incredibly powerful thing.
[00:05:07]
If it's a fast feedback loop, that's excellent. I think we've all been on projects, for an example, if you have a project that takes a long time to build. Console logging might be really frustrating, where you forgot to add a log to a few areas and now you've built and you have to wait on us.
[00:05:20]
So maybe that's the time to reach for it or maybe you've got a lot of errors going on. And what you really need is just a better understanding of how the application works. Maybe even you still use console logging to fix it, but you can use some breakpoints just to learn about your own application, how it works, what's in scope, check things like that.
[00:05:37]
So I'm not prescriptive about how you debug, but it's nice knowing that these tools are there that they can buy and provide a robust amount of information. And in some cases, they can be a lot more helpful, particularly, I think the slow build. We've all been there where we forgot to log in a certain case, then we have to rebuild our whole app again, so.
[00:05:54]
>> Speaker 2: Are there ever cases, or is it possible to persist the code changes in the Sources panel? Or do you have to set up the workspace in DevTools, doesn't it?
>> Jon Kuperman: You'd have to set up the workspace to persist those and [COUGH] it struggles a lot with a lot of build tools.
[00:06:07]
Some things will work okay, like if you have, for example, if you have like SAS or SCSS as your whole build step, Chrome DevTools will persist those changes. It's okay with those, but once you get into, if you've got like Web Pack or Veat, or like any of those, then you'll probably lose that.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops