What is the debugger anyway?

From the very beginning, the debugger sounded like a helpful tool. However, the idea intimidated me. Whenever I dipped my toe into the debugger by writing ‘debugger’ in my code, I was quite overwhelmed by all the words and variables that popped up in a separate window. What did it all mean? I figured this tool can wait.

A few weeks later, the debugger was my new best friend. Thanks to the debugger, I had access to so much more information that could help me figure out what was not working. I could write code within a function in the console and get immediate results without having to save my code, refresh the page, enter input again, and see the outcome.

The language I have been using is Javascript. When doing various assignments and challenges and running into a coding bug, I would just try different things in the code and keep refreshing the browser to see if my end goal was finally working. I was often mystified about what exactly was wrong. Why was this variable undefined when I thought I had defined it? Maybe I need to define it somewhere else? Why did this variable have a really unexpected value? Where was it getting that value from? Again, I was just shooting in the dark trying to figure out the problem and the corresponding solution.

Really discovering the debugger has brought clarity to all these questions…

Now, whenever I get stuck, I add a debugger right in the middle of my function and run my code in the browser, open up the console, and get the inside scoop on what’s happening inside my function.

This has now saved me lots of time, made me very efficient when debugging, and has even gotten me more excited about coding.

Let’s walk through a simple example.

Below is a single page application that I was working on. It’s a simple weekly meal planner, where the user can add meal plans for each day such as ‘tacos’, as well as other notes such as ‘happy hour’ or ‘going to store’. There is also a grocery list and a recipe finder. For the purpose of this example, I will stick to the notes for each day of the week.

My problem was this: When I enter ‘lasagna’ in the ‘Add Notes Here’ form, there is an error in the console.

What does that mean? ‘Cannot read properties of undefined (reading ‘notes’)’ is telling me that ‘notes’ is undefined when calling a variable later on in my code at line 177 (which is the persistNotes function I am using to send the information to the server so that ‘lasagna’ is added to ‘Thursday’). This variable is using the information that I am trying to access here on lines 13 and 14, so that is where the problem is.

When I look at my code, it makes sense to me at first. I want the target of my event listener. I want to know what the day is and what the notes are that I put in. In the HTML file below, I can see that I do have ‘day’ as the name for my form options where the user selects the day. I also have ‘notes’ as the name of the input. So why is it undefined when being called later in my program?

Here is where I could spend a lot of time guessing in my code, refreshing and retrying in the browser, and maybe with no luck.

Or, I can put in a debugger!

Now when I open my console, after entering ‘lasagna’ in the ‘Add Notes Here’ form, the debugger opens:

In the top right I can see my code and where the debugger is. This is especially helpful when having multiple debuggers because I can see exactly which debugger is pausing my code at this moment.

In the middle on the right I see what all the variables are. Generally, the local variables are the ones I am interested in because these are the ones I am working with within my function. In this case, ‘this’, ‘dayID’, and ‘note’ are undefined, while ‘e’ and ‘form’ are defined. By clicking on the little arrows to the left of the variables that are defined, I can find out more information about them.

On the bottom right is where I can write code that will execute exactly where my debugger is. Without the debugger, I am always in the global scope when writing code in the console. However, generally the problem is with the variables that are only accessible within a specific function.

In this example here, I am trying to access the input the user gave, ‘lasagna’. The error I got told me that ‘notes’ was undefined based on the information I was storing in the variable ‘note’. I know that ‘e’ is defined because I can see it in the ‘scope’ box. Let’s see what happens when I enter ‘e.target’ in the console while my code is paused with the debugger:

Looks good so far. So what does ‘e.target.notes’ yield? Let’s put that in the console:

So I am getting something, but not what I want. However, I am seeing here that ‘e.target.notes’ is not undefined at this moment. What I want though, is the value of these notes, not the HTML of the input section. Let me now try ‘e.target.notes.value’:

Voila! That’s what I was missing. So often, just one word makes all the difference, right?

Now when I run the code again, my debugger is still in place and pauses the code. At the top of the page, there are two buttons after ‘Paused in debugger’. The first button enables me to get out of the debugger and my code continues to run until it finishes, or until it hits another debugger. The second button with the little arrow allows me to continue for just one more line of code. This is incredibly valuable because it lets me see how the variables change as the code continues to execute line by line.

As you can see above, I continued past the debugger to line 17 of my code. At this point I passed the two variable declarations ‘dayID’ and ‘note’. If you look down below where the two red arrows are in the ‘scope’ box, you can see that ‘dayID’ now has a value of ‘4’ and ‘note’ now has a value of ‘lasagna’, which was exactly my goal.

You can see above, that ‘lasagna’ was now added to my weekly meal planner. Success! Who doesn’t love lasagna on a Thursday night?

This was a simple error to figure out, but this is the kind of error that got me hooked on using the debugger. By using the debugger, I quickly figured out what I was missing and why it wasn’t working. I could figure out what values my variables had, and how to center in on the information I needed to properly run my code. I now use the debugger almost every day and have not looked back since.

Side Note: Something else that I have found super helpful in more complicated scenarios (though not needed in this example), is that when I am looking at the variables in the ‘scope’ box, I can right click on any variable or any attribute of that variable and then click on ‘Copy property path’. In the case below, I went inside of the ‘e’ variable, or event, and went a little deeper to see some of the attributes for the purpose of this example.

When I right-clicked on ‘innerHTML’ and then copied the path, I got the following:

Again, in this example, I did not need the information, but it has been very useful to me in situations where I can see where the value is that I want in the ‘scope’ box, but I need the exact path. This is especially useful when working with deeply nested objects and running for… in loops. I can then use the ‘step over’ tool as I am going through the for…in loop and figure out the exact path of different values in my nested object at specific points in the loop.