Breakpoints & Logpoints

[00:00:00]
>> Burke Holland: Let's talk about debugging. This is where we really start to crank this knob on VS code from text editor towards IDE pretty hard. And this section is gonna be a little bit dense in terms of the terminology and the concepts that we go over. The hardest part of debugging any application is just getting the configuration right for the application to run.

[00:00:25]
When we're talking about JavaScript in VS Code, there is no configuration required to debug a JavaScript file.
>> Burke Holland: So you can add a breakpoint to JavaScript file like this one. So let's just put it here.
>> Burke Holland: Actually, let's put it up here. And then you can just run this file directly from VS code by pressing f5, f5 is what launches the debugger in VS code.

[00:00:57]
The other way to launch the debugger is to click this green button right here. It's the equivalent of f5 start debugging. So I'm gonna collapse the sidebar and press f5. And by default VS code comes with the node debugger installed. You just get that out of the box.

[00:01:18]
I have included the Chrome debugger for you, and when we get to browser debugging, you're gonna use that. That's an extension, it's not part of VS code, it should be part of the extension pack though. There are other debuggers that come with other extensions. For instance, there is a product called NativeScript that allows you to build mobile apps and it has a debugger.

[00:01:42]
And if you install the NativeScript extension in VS code, you can write any in the script apps and you can debug them on your devices because they've written a debugger for VS code. So provided what you're working with has a debugger, you can debug it in VS code, and that's virtually, I say everything, but it's most things you can probably think of.

[00:01:59]
I don't know if there's a Cobalt debugger. Maybe there is. I don't know, anybody here doing Cobalt? Okay, shocking. All right, let's go ahead and choose Node js here and we're going to let this run and the application is gonna run, it turned my light blue. We've returned from the API and I've set a breakpoint here just by clicking in the left hand side here, so standard debugging.

[00:02:23]
And when we do this, the debug panel automatically pops up, and we can see variables here. We can add watches so we can watch certain things. We can inspect the response here and look at the insights. We can see the data, the results and drill on down and see what's actually coming back from the API that we've got going here.

[00:02:47]
We can also see the call stack. So we come up here, we can move through the call stack. Here's all of our watches and then all of our breakpoints down here, so we can disable them just by selecting them here. And then lastly you can see what scripts are actually loaded into the debugger at the moment.

[00:03:06]
So I'm gonna go ahead and continue on here, so let's move through this. So that's just your standard debugging scenario with a simple JavaScript application. Now you can do conditional breakpoints as well, just like you can in every other editor. But VS code also has something in addition to breakpoints, that's called logpoints.

[00:03:30]
In the case of this application, I've got a loop here and we might want to know what this item is, okay? So the way that we would normally handle this is we would remove this line, and we would say, console.log(item), okay? Now, you can do this. But it's actually easier once you get the debugger working.

[00:03:56]
We can put our comment back here. It's easier to use logpoints to do the same thing. So what I'm gonna do is I'm gonna right-click here, and I'm gonna say add a logpoint. And then logpoints are basically console log statements that the editor just runs for you without you having to stop your project, add a line in and then restart.

[00:04:20]
And so you can say here, item, like this and hit Enter. And you'll have the logpoint. And if we run this here, I'm gonna run it, actually, let's run it in the debugger here.
>> Burke Holland: And get to our debug console, and you can see that it's logged out the item that we put there.

[00:04:44]
Now you notice that I put this thing in braces. That's because if you put text in here, like if I was to just put item, what do you think it would log out?
>> Speaker 2: Item.
>> Burke Holland: Item, right. So it's string interpolation is what it is. So we can say, current item is, like this and let's go ahead and run this again.

[00:05:11]
This time from here, current item is, and it puts it out. And you can also run execute methods in here. So you can do this.
>> Burke Holland: Let's run that.
>> Burke Holland: And it's stringifying the result. Now, an interesting thing about logpoints is that if they fail, it doesn't tell you.

[00:05:41]
So for instance, in axios, which is the library that I'm using to make this HTTP call, I'm gonna remove this logpoint. Actually, we can leave it on this line. In axios, you cannot stringify the response object because it has cyclical dependencies. In other words, it is dependent on itself, dependent on itself, dependent and that thing is dependent upon the parent.

[00:06:05]
And when that happens, you can't serialize it. And so if we try to do that, if we came in here and said, JSON.stringify and then we try to stringify the response, that would throw an error but here's what happens when we do it in a logpoint.
>> Burke Holland: You see what happened, nothing.

[00:06:28]
So if you are ever using a logpoint and nothing's happening, it's because whatever you're trying to do is not a valid statement. So you need to go back and try to figure it out. It took me a long time, I spent a lot of time working with logpoints and they wouldn't work and like what is going on, logpoints aren't working.

[00:06:43]
No, it's because I'm doing something that is wrong. It would be nice if logpoints told you, hey, there's an error but apparently it doesn't do that. So if your logpoint isn't working, that's why. You can do other things on your logpoints, you can evaluate an expression. So you could say like item, select item dot or let's just say results.length is greater than zero, right?

[00:07:11]
So this will log whether or not that's true or false. And you can also do a hit count, so what you can say on the hit count is, break when the hit count condition is met. So we could say, I want to know if the response length, sorry, it's results.length, so response.data.results.length is greater than 2.

[00:07:33]
In other words, if there are more than two items in the response, I wanna know about it, go ahead and log it out. So you can use expressions and hit counts along with your logpoints. So go ahead and remove this logpoint here. All right, that is the most simple example of debugging that we possibly have.