Introduction to Dev Tools, v3

Step Through Debugging Solution and Q&A

Jon Kuperman

Jon Kuperman

Introduction to Dev Tools, v3

Check out a free preview of the full Introduction to Dev Tools, v3 course

The "Step Through Debugging Solution and Q&A" Lesson is part of the full, Introduction to Dev Tools, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jon live codes the solution to the Step Through Debugging exercise. Student's questions regarding what can be put in the Watcher, how to avoid issues with Chrome extensions, when watcher values should be set, and how to persist changes without using workspace are also covered in this segment.


Transcript from the "Step Through Debugging Solution and Q&A" Lesson

>> All right, so we got some really good questions during the exercise. So I think I'm going to solve the exercise with everybody together and then I've got I think three that I saw and then if anybody else has any will go through those too. So yeah, so for the step through debugging Like usually when you have error, the console is always like a good place to start, like usually anything that throws will end up in the console.

So the first thing I see is like this type error. So the console is a nice way to get to the sources tab as opposed to looking through the file yourself. So I'll go ahead and click on it and it'll take me over here and this specific error was documented, that newElement is not a function.

So if I go to my sources over here. Then maybe do like a Google search or something like document new element. I can see that the actual API is createElement, not new element. So we can go ahead in our IDE. We can go ahead and change that to createElement.

Then I'll hit save, and then I'll refresh. So now there's no more console error and I saw some folks kind of getting to here. It's like, okay, it's not a JavaScript error, but why is it rendering like this giant list of undefined. So we go back into our sources and we can just do something set a breakpoint.

And so I'll set a breakpoint and then I'll refresh the page. So we hit this break point, it stopped here, I can use the watch over here. So for example, I can watch on li, and I can see that it is in fact, a list item. So that I mean that looks good.

And then I can add another watch item and I can make it item. And so I can see as an object with a bunch of stuff. So what it looks like we're doing is we're setting li.innertext to item.fact. And we can see if we hover over the fact is set to undefined whereas item is set to an object.

So I can go ahead and I can browse in here, trying to see what's going on here. I can see that there isn't a fact property, but there is a text property. So I can go back to my code here and change it from item fact to item text and hit save again.

I'll remove this break point for now and refresh. And now we've got all these facts about cats, which I'll try very hard not to read and in fact move on with the rest of the content but a couple of things here. There's a couple different ways you could solve it.

Again, I'm kind of just trying to highlight like, I think normally what I would have done was console logged item here, but it is kind of nice to combine like the debugger was like actually like take that second to breathe and look around at the function. Look around with the object, see what you have access to, what you don't.

It's kind of a nice way to do it. We got a couple questions that were really good. So one question was about what you put in watchers. And it was like, do you have to specify what you put in the watch? Or can you just watch everything? So the answer is that you do have to specify what you put in the watch.

You can't put like a wild card in. But if I go ahead and I refresh here, or maybe make a breakpoint here and play to it, I can close what's in my watchers and I can look at my scope. And so if you come down here into scope and you'll get local scope, you can see everything that you do have access to in this function.

You can also see everything you have access to in the global function. So if you wanna browse what you have access to scope is the place to do that. If you want to keep an eye on a very specific one watch is the place to do that. We had another question was my extensions are getting in the way, and so you kind of have two options.

If you notice a Chrome extension is getting in the way one is to open an incognito window and do the same thing there. The other one is you can go to Window and extensions. And then you can just deactivate all of them here so that that won't uninstall them, right like here, you can just deactivate LastPass and close it and then refresh the site again so you can kind of go either way.

It is a tricky thing. It's bitten me a lot before in real life production cases where I'm experiencing something and it turns out to be a Chrome extension. So I think it's a good idea to either turn them off. One other cool thing you could do is I oftentimes, like I'll have Chrome as my daily driver for my browser.

And then, I'll download Chrome Canary, which is their like, pre release, build. I'll use Chrome Canary with zero extensions. That'll be like my, what I use for dev tools, whereas like Chrome will be like what I use for browsing. So you have a couple of different options there.

But it is good to keep in mind that that the extensions can break it.
>> I have a quick question for the watch.
>> Yeah.
>> If you're setting the watch do you also have to set a breakpoint on this specific element that you're watching where those specific variables that you're watching?

Or good at if you set it, let's say after the elements when you call it, would that still work?
>> Yeah. So basically what this is gonna do is every time a breakpoint gets hit, it will update the values in here. So like if you had like a function that set foo and then way later you put a break point it would still have access to foo because that's totally fine but as for like keeping track of, it'll update every time you either hit a break point or like you step in or out of a function that will update then.

So it doesn't really matter where you place it but this will only post data when you've like hit a breakpoint basically. Somebody had asked, okay, without doing workspaces, is there a way to get your changes so that they will persist through a refresh, right? So not necessarily writing to disk and that whole thing, but I just want to be able to like change some JavaScript, refresh the page and see it execute.

There is a way to do that. And so to do that, you come over here to the left panel, where we were on page before, and you click over here to overrides. And what you have to do is you have to create or give Chrome a folder to store all these little diffs and it can be literally anything.

So you can click Select Folder for overrides, you can make your own folder that's no problem. Like I can make a folder and call it like FUBAR or something like that. You could put it in your documents so you can make it, Chrome, local overrides folder, anything like that, it's fine.

When you select it, you'll have to go through the permissions process or like allow and your OS might ask to. But once that is that, then we can do things like we could go to the body. We could do you know, like background color red or something like that.

And now when we refresh, it'll stay red. And we can do that with our sources panel and our JavaScript, everything like that. So if you're that's, that's always good for like, if you're, especially with JavaScript that runs once, I think somebody had asked about this earlier to where it's like, you load the page and you make an edit and you want to see it and then you refresh which gets the page from the server again, so you've lost your edit, like that kind of thing.

So if you go to sources overrides and set up an override, you'll be able to get that

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now