js DevTools browser extension is great for debugging Vue apps. With it, you can view the component and global store data, as well as see a timeline of component, keyboard, and mouse events. Despite this, though, there are still plenty of times during Vue development where I still reach for console log. js apps.
Now all major browsers ship with a built-in JavaScript debugger. However, VS Code actually comes with its own built-in debugger so that you can debug your code directly in the source files. Therefore, if you aren't familiar with JavaScript debuggers, no problem. You'll see how they work in this lesson.
If you are familiar with them though, but have never used the debugger built right into VS Code, then stick around as well because I'll show you how to get that set up. All right. js. Next, let's define a variable a that equals 1, then a variable b that equals 2, and a variable c that equals the sum of a plus b.
Now, let's say that this was a more complicated script, and I wasn't sure what variable c equaled. Well, I could console log c to get that answer. However, this means I'll probably end up removing this line again after I have my answer. Or if I forget to remove the line, a number of different downsides will occur, right?
I could have just random console logs in my production environment, just extra noise and source control, and maybe, worst of all, a lot of console logs showing up while I'm debugging, which makes it difficult for me to see the console logs that are actually pertinent to my current issue. Plus the only variable that I really get visibility into is the one I provided in console log. In this case, that is the variable C. If I wanted more information, like the value of A, all the available global variables, and so on, I'd have to manually add those to the console log.
Alright, so let's remove that console log and check out a better way. First though, let me make sure I have a particular setting so that this will work appropriately. I'll open up my settings with the command palette and search for margin. The setting that I want to enable is this first one here called editor glyph margin.
What that's going to do is add some margin to the left hand side of my line numbers. And when I hover over it, you can see these little red dots appearing. These red dots are called break points. If I click on one of the red dots, it lights up and I can move away and it stays in place.
This instructs VS code to pause during the execution of my script at this particular breakpoint or at line 3 and then provide me with all kind of details about the current state of the program. Let me show you what that looks like. In the command palette, I'll type debug and then select the JavaScript debug terminal command. This opens up a new terminal at the bottom of VS code where I can debug our test script with node.
After I hit enter, we get this message debugger attached. And in the file, you can see the line where I added the breakpoint is highlighted in yellow. So currently the script is paused just before the execution of line three. And in the debug panel on the left-hand side is the data that's going to be most helpful for us.
There, we're able to see all the local data of this JavaScript module. Some of it is data that you might not have even thought about. There's a dir name. and a file name, a module variable, and also the local variables that you'd probably expect to see, like A and B.
What's cool about this is we can see the actual values that these variables are set to at this point in the script. C is still undefined though. That's because line 3 hasn't quite executed yet. To continue on with the program, let's click this little blue arrow up at the top of the screen, to process the execution of the program by one more line.
And when we do that, you can see that C gets the value of 3. When we press the blue arrow again, since we're at the end of the script, execution stops and all the data on the left-hand side disappears. Awesome. Now, the really cool thing about this is we can not only debug scripts that run in the terminal, but we can also debug a browser application served by Vite in the JavaScript debug terminal.
I'll run the command to start the development server. This boots up the dev server on port 3000. Next, let's command click on the displayed URL to open the app. And just a word of warning here, don't visit that URL directly in your browser because it won't work the same.
Great, we've got the app running in Chrome now. view to kind of replicate our little math problem we saw before. value. And it looks like we'll need to import computed from view.
Now, on the line where we defined c, I'll add a breakpoint just like we did previously. And then over in the browser, let's give the page a refresh. As soon as I do, we get sped back over to VS Code. where the line with the breakpoint here is highlighted.
On the left-hand side, you can see all the data for the setup block. A is a reactive ref with the value of 1, and B a reactive ref with the value of 2. If this looks a little funny to you, that's okay. The reason why is because we're getting the raw JavaScript data here, instead of the more prettified version that you might be used to seeing in the Vue DevTools.
But... This is really what a reactive ref looks like in pure JavaScript. Of course, just like before, C is still undefined. Now I'll click step over just like before, so hopefully we can see the value of C.
Instead, though, we kind of get into the internals of view, and I really don't want to have to deal with all that. So let's do a little bit of a workaround that's not great, but is really the best way I found. to solve this issue. view and then add just a placeholder variable after the const of C here.
We'll say test equals true, okay? Then I'll add my debug breakpoint on that line instead of on line seven. I'll stop the development server down here and then restart it. Once I reopen my browser, We're back in our script section at const a Not really sure why it stopped there to be honest, but let me read a breakpoint here and then hit play so play moves you to the next breakpoint and Yeah, perfect.
Now we are stopped on line 8 and C is a computed ref and indeed it has the value of 3 When we're done seeing what we want to see we can hit play to finish out the execution of the script And in the browser, everything is good to go. Don't worry about this little restore pages dialog here. This is just from when we restarted the debug session. All right, now let's say that I want this same kind of insight on code that runs not during page load, but on some kind of user event.
Well, we can do that too. To show you, let's add a button in the template section and we'll label it click me. For the on click event, let's call a function called handleClick. Then we can define that function and this time use fetch in order to make an async request to the JSON placeholder API.
This will return a list of posts as JSON. And for that to wait to work, I will have to make this function async. Now let's loop over each of the posts. And in a real application, you might want to perform some kind of logic here.
where you'd need to know what each post looks like. log to gain that insight, but let's try using a breakpoint instead. Okay, after saving the file, I'll go back over to the browser, and it looks like something is broken, so I'll just give the page a refresh. We are taken back to VS Code.
Let's just hit play to move through all this. Awesome. In the browser I can now see my click me button and let's click it. Perfect.
We're brought back to the code again and now on the left hand side for local variables I can see some of the information that we're looking for. Post is currently undefined though because we've stopped on line 9. Once again I'm not sure why the break points aren't quite honoring what we set. Maybe it has something to do with the reformatting that occurred when I hit save, but let's just hit the step over button to go to the next line.
And now response is defined. Let's keep going. And post is defined. We can see that it's an array of a hundred posts.
Okay, that's pretty cool. And then I want to step in to the for each loop. And sure enough, now I've got the value of post. This is the post as it would exist on the first iteration of the loop.
I can do step over and then step over once more. And we're to the second iteration of the loop where we get the post with the ID of 2. I can do it one more time. And yeah, you can see how we can individually step through every single iteration of this loop.
In past experience, I found the debugger especially helpful in loops like this. because if we just use console-log, we would literally get 100 logs to the console that would be difficult to sift through. But with the debugger, we can take a look at each post, individually, one at a time, without any extra noise. js DevTools, or even a replacement for console-log.
In fact, I very rarely use it. But I did find that in my experience with PHP, using a PHP debugger that works the exact same way came in handy fairly often. So, as easy as it is to set up, no doubt it's worth knowing that it exists and every once in a while you might find a very good use case for it. js DevTools browser extension is great for debugging Vue apps.
With it, you can view the component and global store data, as well as see a timeline of component, keyboard, and mouse events. Despite this, though, there are still plenty of times during Vue development where I still reach for console log. js apps. Now all major browsers ship with a built-in JavaScript debugger.
However, VS Code actually comes with its own built-in debugger so that you can debug your code directly in the source files. Therefore, if you aren't familiar with JavaScript debuggers, no problem. You'll see how they work in this lesson. If you are familiar with them though, but have never used the debugger built right into VS Code, then stick around as well because I'll show you how to get that set up.
All right. js. Next, let's define a variable a that equals 1, then a variable b that equals 2, and a variable c that equals the sum of a plus b. Now, let's say that this was a more complicated script, and I wasn't sure what variable c equaled.
Well, I could console log c to get that answer. However, this means I'll probably end up removing this line again after I have my answer. Or if I forget to remove the line, a number of different downsides will occur, right? I could have just random console logs in my production environment, just extra noise and source control, and maybe, worst of all, a lot of console logs showing up while I'm debugging, which makes it difficult for me to see the console logs that are actually pertinent to my current issue.
Plus the only variable that I really get visibility into is the one I provided in console log. In this case, that is the variable C. If I wanted more information, like the value of A, all the available global variables, and so on, I'd have to manually add those to the console log. Alright, so let's remove that console log and check out a better way.
First though, let me make sure I have a particular setting so that this will work appropriately. I'll open up my settings with the command palette and search for margin. The setting that I want to enable is this first one here called editor glyph margin. What that's going to do is add some margin to the left hand side of my line numbers.
And when I hover over it, you can see these little red dots appearing. These red dots are called break points. If I click on one of the red dots, it lights up and I can move away and it stays in place. This instructs VS code to pause during the execution of my script at this particular breakpoint or at line 3 and then provide me with all kind of details about the current state of the program.
Let me show you what that looks like. In the command palette, I'll type debug and then select the JavaScript debug terminal command. This opens up a new terminal at the bottom of VS code where I can debug our test script with node. After I hit enter, we get this message debugger attached.
And in the file, you can see the line where I added the breakpoint is highlighted in yellow. So currently the script is paused just before the execution of line three. And in the debug panel on the left-hand side is the data that's going to be most helpful for us. There, we're able to see all the local data of this JavaScript module.
Some of it is data that you might not have even thought about. There's a dir name. and a file name, a module variable, and also the local variables that you'd probably expect to see, like A and B. What's cool about this is we can see the actual values that these variables are set to at this point in the script.
C is still undefined though. That's because line 3 hasn't quite executed yet. To continue on with the program, let's click this little blue arrow up at the top of the screen, to process the execution of the program by one more line. And when we do that, you can see that C gets the value of 3.
When we press the blue arrow again, since we're at the end of the script, execution stops and all the data on the left-hand side disappears. Awesome. Now, the really cool thing about this is we can not only debug scripts that run in the terminal, but we can also debug a browser application served by Vite in the JavaScript debug terminal. I'll run the command to start the development server.
This boots up the dev server on port 3000. Next, let's command click on the displayed URL to open the app. And just a word of warning here, don't visit that URL directly in your browser because it won't work the same. Great, we've got the app running in Chrome now.
view to kind of replicate our little math problem we saw before. value. And it looks like we'll need to import computed from view. Now, on the line where we defined c, I'll add a breakpoint just like we did previously.
And then over in the browser, let's give the page a refresh. As soon as I do, we get sped back over to VS Code. where the line with the breakpoint here is highlighted. On the left-hand side, you can see all the data for the setup block.
A is a reactive ref with the value of 1, and B a reactive ref with the value of 2. If this looks a little funny to you, that's okay. The reason why is because we're getting the raw JavaScript data here, instead of the more prettified version that you might be used to seeing in the Vue DevTools. But...
This is really what a reactive ref looks like in pure JavaScript. Of course, just like before, C is still undefined. Now I'll click step over just like before, so hopefully we can see the value of C. Instead, though, we kind of get into the internals of view, and I really don't want to have to deal with all that.
So let's do a little bit of a workaround that's not great, but is really the best way I found. to solve this issue. view and then add just a placeholder variable after the const of C here. We'll say test equals true, okay?
Then I'll add my debug breakpoint on that line instead of on line seven. I'll stop the development server down here and then restart it. Once I reopen my browser, We're back in our script section at const a Not really sure why it stopped there to be honest, but let me read a breakpoint here and then hit play so play moves you to the next breakpoint and Yeah, perfect. Now we are stopped on line 8 and C is a computed ref and indeed it has the value of 3 When we're done seeing what we want to see we can hit play to finish out the execution of the script And in the browser, everything is good to go.
Don't worry about this little restore pages dialog here. This is just from when we restarted the debug session. All right, now let's say that I want this same kind of insight on code that runs not during page load, but on some kind of user event. Well, we can do that too.
To show you, let's add a button in the template section and we'll label it click me. For the on click event, let's call a function called handleClick. Then we can define that function and this time use fetch in order to make an async request to the JSON placeholder API. This will return a list of posts as JSON.
And for that to wait to work, I will have to make this function async. Now let's loop over each of the posts. And in a real application, you might want to perform some kind of logic here. where you'd need to know what each post looks like.
log to gain that insight, but let's try using a breakpoint instead. Okay, after saving the file, I'll go back over to the browser, and it looks like something is broken, so I'll just give the page a refresh. We are taken back to VS Code. Let's just hit play to move through all this.
Awesome. In the browser I can now see my click me button and let's click it. Perfect. We're brought back to the code again and now on the left hand side for local variables I can see some of the information that we're looking for.
Post is currently undefined though because we've stopped on line 9. Once again I'm not sure why the break points aren't quite honoring what we set. Maybe it has something to do with the reformatting that occurred when I hit save, but let's just hit the step over button to go to the next line. And now response is defined.
Let's keep going. And post is defined. We can see that it's an array of a hundred posts. Okay, that's pretty cool.
And then I want to step in to the for each loop. And sure enough, now I've got the value of post. This is the post as it would exist on the first iteration of the loop. I can do step over and then step over once more.
And we're to the second iteration of the loop where we get the post with the ID of 2. I can do it one more time. And yeah, you can see how we can individually step through every single iteration of this loop. In past experience, I found the debugger especially helpful in loops like this.
because if we just use console-log, we would literally get 100 logs to the console that would be difficult to sift through. But with the debugger, we can take a look at each post, individually, one at a time, without any extra noise. js DevTools, or even a replacement for console-log. In fact, I very rarely use it.
But I did find that in my experience with PHP, using a PHP debugger that works the exact same way came in handy fairly often. So, as easy as it is to set up, no doubt it's worth knowing that it exists and every once in a while you might find a very good use case for it.