In this video we're going to talk about how we can best debug our node j s applications.
So we'll talk about some debugging strategies and we'll also explore the debugging tools that node provides
you to make it much easier to fix your broken apps.
We'll be exploring the node debugger which integrates directly with the Chrome developer tools GIVING
YOU A NICE GOOEY for debugging your back end applications.
It's a really great way to figure out why your apps are not working now in general.
There are two types of errors so we're gonna run into when working with no J S we're gonna have things
go wrong and we're gonna get an explicit error message.
So we've already seen that when we've made a typos in the class and the other type of error is when
things go wrong and there is no error message which likely means we have some sort of logic problem
in our code that we're gonna need to first figure out where it is.
And then second adjust to make it actually work.
Now we can employ these same strategies for debugging both types of errors.
So let's kick things off by exploring some of the basic tools that node provides the most basic debugging
tool we have is something we've already used dozens of times before.
Console dialogue.
So let's say that for some reason this message never seems to print.
Even when I try to add a duplicate I'm not getting note title taken printing.
What would I do to fix this.
The first thing I would do is look at the contents of duplicate note right here to make sure it's what
I'm expecting it to be.
So what would I do.
Well I could just use console dot log I could print out the duplicate note variable allowing me to see
its value when I run the program.
NO CONSOLE dialog might get a bad reputation on medium dot com posts or they say you should never use
console dialog for debugging.
I think that's all overblown.
Everyone wants things to be black and white.
This is the only way that way is bad and in general it's all about finding the right tool for the job.
I use console dot log all the time and client projects to quickly just dump a value to the terminal
so I can check it out.
Right here we could now run the application to dump that and see what's going on so I could do something
like run node app dot J.S. using the ad command.
I'll provide a title for my new note.
Let's go ahead and set it equal to something like courses then I'll go ahead and I will create a body
option as well setting that equal to something like node j s perfect.
So we have our new note being added.
And as that program runs we're gonna be able to see the value of duplicate note when we run it here.
I can see it's undefined which is good when I run it again.
I can see now the duplicate has been found and we're getting that printed so hopefully we would be able
to use that information to figure out what's up now.
If not we would want to take things one step further if duplicate note is bad.
That means either the notes array isn't what we're expecting or maybe the title argument is in what
we are expecting.
So what do we do from there and we continue to log things so I could console dialogue or something like
title and I could even console log notes down below.
If I were to rerun the program we now get even more information making sure we can figure out exactly
why our application is running the way it is.
No console log is great for a lot of situations but if you find yourself logging out five or six or
seven different values it can really become a burden.
It can be annoying to add all of those console dot logs around your program.
Then remember where you put them and actually remove them.
So console that log is the most basic tool available to us for debugging our apps.
Next up is the node debugger and that is nodes built in debugging tool which integrates with the 8 and
the Chrome browser.
The debugger like console dialog needs to be added at a specific point in your application.
So let's say that right here once again I want to explore the variable values at this point in time.
If I want to pause the program here I can use a debugger that's gonna stop the application at this point
in time.
Then I can use the developer tools which we'll see in a second to look at any values I want I could
look at notes or duplicate note or title or body or anything else that existed.
And obviously this gives us a bit more flexibility with console dialog.
We have to manually list out the things we want to see with debugger.
We can just add the debugger statement one time and once we get to the dev tools we can look at everything.
Now with this in place our application isn't going to change how it runs by default.
Down below I'm going to rerun the command I ran before.
It is indeed going to pass through this line of code.
But what happens.
Nothing happens.
We just see our message which comes from the line down here.
So this line ran.
Which means that this line definitely ran but the program didn't stop.
When we have the buggers in our application they're not going to pause the program by default.
We have to run node with a special option to get that done and to do this we use node followed by inspect.
So node inspect.
Then we add everything we would normally add so I could add the script name aspect J s like so.
And in this case I can also add my command line arguments afterwards so I could set up the ad command
I will provide a value for a title I'll use courses once again and I'll also provide a value for a body.
Once again using node j.
S So now by just adding inspect in there and running the script we're gonna get much different output.
This is Andrew from the future with a quick update.
So as we run that command some of you running on Windows you're gonna get an error you're gonna get
the error that we're seeing here.
So right here on the screen I have two commands I have the command we just ran up top and I have an
alternative command down below.
Now as you run that first command you might get the error that's shown just below it right here that
is time out 2000 waiting on 1 2 7 0 0 0 1 on Port 9 to 2 9 to be free.
So if you run the command that we just typed out and you get that error this update is for you.
So I've been digging around a bit in the issues and this is an actual problem which means that there's
not something we can really do on our machines to fix this.
We have to wait for a fix to be released.
Then we can install a new version of node and hopefully things start to work.
For now though if you are running into that error the second command down below that should allow you
to continue on exactly as we're seeing in the video.
The only difference is that the command is a bit different.
So up top we have node inspect down below.
We have node space hyphen hyphen inspect hyphen be our K so Baquet is short for break that second command
is going to run the inspector it's gonna break on that first line which means that we're still gonna
be able to use Chrome to inspect our application as it runs.
So once again this update only applies to users on Windows who are actually getting the error shown
in red.
If you're not getting that error I'd recommend using the first command as it's more modern.
If you are getting an error for the moment I'd recommend running that second command hopefully in the
future node fixes this issue and I can remove this update altogether.
All right that's it for this update.
If you have any questions just open a question in the course Q and A and we'll work with you to get
unstuck and back on track.
See you soon the output we're seeing here is node letting us know that a debugger is now up and running.
We can see debugger listening on followed by this you are L Now we can head over to Chrome to actually
inspect our application over in the Chrome browser.
What I'm gonna do is close down all of the open tabs I have so far.
We don't need those anymore and we're going to pull up a specific you are all it is chrome colon forward
slash forward slash inspect.
Now remember the node debugger it's using the built in V8 debugger tools.
That means that Chrome which also uses V8 is currently the only browser we can inspect our node applications
using.
So if you normally use Safari or Firefox or some other browser you're not going to have the exact same
debugger integration.
I definitely recommend grabbing chrome for the rest of the class even if you only use it for debugging.
Note now right here what can we do.
Well we can see we have some stuff under remote target under remote target.
I have two targets I have one at the port and then I have one at these shorthand local host and the
end of the day both are the exact same process.
They're just duplicates.
Now if you're seeing nothing under remote target that likely means you have a mis configuration.
Some chrome browsers for some reason have altered configuration details if you click that configure
button you should see two values inside of here.
Local host port 9 2 2 9 then 1 2 7 0 0 dot one on port 9 2 2 9.
If you don't have both of those go ahead and add them into the mix then if you refresh the page you
should see the target showing up.
If that still doesn't work as always just crack open a question in the queue and.
And I'll work with you to get unstuck and back on track.
Now from here we can actually inspect our application and we can pause at that point in time.
We put the debugger statement and view all of our applications variables and values.
Let's get started by clicking inspect so we can actually open up a new instance of the debugger tools
for debugging our node j J.S. application.
So right here we have the Chrome developer tools although obviously some stuff is not here.
For example we have our tabs up above in the browser.
We would have something like an elements panel that doesn't make sense for node since the elements panel
allowed you to debug your hcm UML document and we don't have an HDMI document here but we do have two
very important tabs we have the console tab and the sources tab both of which we'll be using to debug
our application.
Now there is a lot going on with this source's tab so let's take a quick moment to break down what's
happening in the middle.
We have our file app.
Yes exactly as we have it over inside of Visual Studio code with one very important difference.
You'll notice on line one of our program we define the chalk variable over here that does indeed happen
but there's a whole bunch of stuff added beforehand from the very first character of line one all the
way over here to where the const chalk is defined.
This is all been added.
Now this is a function that wraps your node j s script.
So with other programming languages you might have a main function you define when you run the program.
That's the function that starts up your application with no J S we don't have that.
It just runs your entire script top to bottom.
So to make node actually be able to run your program through the eight your code is wrapped in this
function right here.
Now this function does indeed get closed as well.
So if I scroll all the way to the bottom of the file I can see the closing of the curly braces and the
parentheses.
So this function can be considered our main function of sorts and it provides to our application a few
different values we can access.
We'll be exploring the others later throughout the class.
But one of them is required which we've already used extensively to load in NPM modules Node core modules
and the other scripts we've created.
Now we can actually add our project folder to the developer tools on the left hand side.
We can get that done by clicking add folder to workspace under file system.
I'm gonna go ahead and do just that and I'm going to navigate to my notes app directory.
So from the desktop I've added the node course folder in there I have notes app which is the directory
we've been working with in visual studio code.
I'm going to select that directory and we can see that after we allow access to that folder what we
see changes a little bit.
Right here we no longer have that wrapping function.
We just have the code we wrote exactly as we wrote it on the left hand side.
We could even dig through the other files in our application and we have this little green icon to show
which is the currently active file when I am debugging node j asked I like to keep the console open
as well.
We can actually have both sources and console open by keeping these sources tab open and using the escape
key to toggle the console.
So I'm going to leave that up as well so we can view the output from our program and we can even use
this to run various commands which we'll see a little bit later.
Now it's important to note that at this point in time not a single line of our program has executed
right here.
Line 1 is highlighted in blue.
This is the line that the debugger is currently paused at.
And when it's paused at a line it hasn't executed that line yet.
So we haven't even defined this chalk variable on the right hand side.
We have a lot of information about where our program currently is.
So I have information about the call stack.
I have the scope.
We currently have access to an up above.
I have tools for working through our application.
So currently the debugger is paused.
We need to go ahead and manually tell node to continue running the application.
So at this point in time we can go ahead and do just that.
What I'm going to do is click this blue play button that's going to resume executing our script and
this is going to run until it's told otherwise.
And one of the things that's going to posit is the debugger statement which we do have in our program.
So I'm going to click play it is going to run the script.
Now you can see we are over in notes dot.
J.S. Right here on line 8 where we defined that debugger statement.
And at this point in time we can really start to debug our program at this point in time.
So over here in the call stack we have some useful information about exactly where we are in the program.
We can see we are on line 8 of notes dot J.
S in the ad note function and down below under scope we can actually see access to the variables we
have in scope.
So I have duplicate note I have notes I have this title and body and I can see all of those values right
there.
Now we can always dive deeper into any of those values by running some statements from the console so
down below.
For example I could access body by typing it out I can hit enter and I can get that value.
I could even grab something like one of the notes so I could go ahead and reference the notes or write
grabbing an item by index using my square brackets.
I'll go ahead and grab the second item with the index of one I hit enter and I can dump that object
to the console and make sure its individual properties are what I'm expecting.
So with the debugger statement we can really dive deep into the current state of our application.
At that point in time and we can figure out exactly what's not looking right and what needs to change
now as we run through our program eventually we will get to the end and that's what's going to happen
if we click play again since we don't have any other debugger statements.
It is going to work through to the end and now we're all done.
We have ran through the application and down below.
I am seeing the console dialog note title taken.
Now unfortunately chalk can't style the output in the debugger but that's OK as that's just a little
utility to make our applications a little nicer it's not an essential piece to the puzzle at this point.
Our application has finished and if I closed down the developer tools I can see that on that inspect
page there is no longer a remote target available.
Now if I wanted to run through the program again and debug things I can run a single command from the
debugger in the terminal.
Right here I can run restart that's going to start the program again.
I can see I now have a new remote target and I can inspect the application again working through it
from beginning to end looking for whatever I happen to be looking for.
Now at some point we're gonna be all done with the inspector and we can always shut it down by heading
over to the terminal and using control C twice when we do that.
It's going to exit the process bringing us back to the command line where we can do whatever we want.
We could install a new NPM module or we could run our node application without inspect if we fixed the
issue where debugging it from there or we can go ahead and remove that debugger statement bringing our
application back to the state it was when we first started.
So there we go a couple of tools we can use to debug our apps.
We explore a console dot log as well as the debugger in the next video we're going to continue working
through debugging.
I'm excited to get to that.
So let's go ahead and jump right in.