Learn how to debug JavaScript using the DevTools browser debugger

Learn how to debug JavaScript using the DevTools browser debugger

Debugging is one of those skills at the heart of a programmer’s business.

Sometimes we try our best, but the program does not work properly, for example it crashes, it is just slow, or it prints out wrong information.

What do you do when a program you’ve written doesn’t behave as expected ?

You start to debug it.

Determine where the error might be

The first step is always to look at what is going on and try to determine where the problem is coming from. Is this a problem in the environment? Is it a problem with the contribution you made to the program? Is this a one-time crash due to excessive memory usage? Or does this happen every time you run it ?

These are all key information to start moving in the right direction when determining a problem.

Once you have an idea of ​​where the error is coming from, you can start checking that specific part of the code.

Read the code

The easiest way to debug, at least in terms of tooling, is to read the code you’ve written. Aloud. There is something magical about hearing our own voice that doesn’t happen when you read in silence.

Often times I have found problems this way.

Using the console

Using the console

If reading the code doesn’t tell you anything, the next logical step is to start adding a few lines in your code that can enlighten you.

In JavaScript front-end code, what you will often do is use alert()and console.log (and his cool friends).

Consider this line:

Somehow the result is not calculated correctly, so you can start by adding alert(a)and alert(b)before calculating the result, and the browser will open two warning panels when executing the code.

It works fine if what you are switching to alert()is a string or a number. As soon as you have a painting or an object, things start to get too complicated to alert(), and you can use the console API . Starting with console.log():

The value is printed in the JavaScript console of the browser developer tools. For convenience, I explain debugging in Chrome DevTools here, but the general concepts apply to all browsers, with a few differences in terms of what features are supported.

Chrome development tools

The value is printed in the JavaScript console of the browser developer tools. For convenience, I explain debugging in Chrome DevTools here, but the general concepts apply to all browsers, with a few differences in terms of what features are supported.

Chrome development tools

The result of the console.log()calls are printed to the JavaScript console. It is a tool more or less common to all browsers:

Browser console

The tool is very powerful and allows you to print complex objects or tables and you can inspect all properties of them.

The debugger

The debugger is the most powerful tool of browser development tools, and it can be found in the Sources panel:

The debugger

The upper part of the screen displays the file browser.

You can select any file and inspect it on the right. This is very important for setting breakpoints, as we will see later.

The lower part is the actual debugger.

Stopping points

When the browser loads a page, JavaScript code is executed until a breakpoint is hit.

At this point, execution is halted and you can inspect everything about your running program.

You can check the values ​​of the variables and resume the execution of the program line by line.

But first, what is a breakpoint? In its simple form, a breakpoint is a breakpoint instruction inserted in your code. When the browser meets it, it stops.

This is a good option during development. Another option is to open the file in the Sources panel and click on the number of the line to which you want to add a breakpoint:

Added breakpoint

Clicking the breakpoint again will remove it.

After you add a breakpoint, you can reload the page and the code will stop at that execution point when it finds the breakpoint.

When you add the breakpoint, you can see in the Breakpoints panel that form.js in line 7 has the breakpoint. There you can see all your breakpoints and temporarily deactivate them.

There are also other types of breakpoints:

  • XHR / recover breakpoints : triggered when a network request is sent
  • DOM breakpoints : triggered when a DOM element changes
  • Event listener breakpoints : Triggered when an event occurs, such as a mouse click
Breakpoints

Scope

In this example, I set a breakpoint in an event listener, so I had to submit a form to trigger the it:

Triggered breakpoint

Now all the variables that are in scope are printed, along with their respective values. You can modify these variables by double-clicking on them.

Look at variables and expressions

Right at the Reach panel there is the Watch panel.

He has a +button that you can use to add any expression. For example by adding name will print the name value of the variable, in the example Flavio. You can add name.toUpperCase()and he will print FLAVIO:

Watch expressions

Resume execution

Now all scripts are stopped since the breakpoint stopped execution.

There is a set of buttons above the « Paused on breakpoint » banner that allows you to change this state.

The first is in blue. Click on it to resume normal script execution.

The second button is step over , and it resumes execution until the next line, then stops again.

The following button performs an enter in operation: enters the function being executed, letting you enter into its details.

Exit is the opposite: returns to the external function calling it.

These are the primary ways to control the flow while debugging.

Edit scripts

From this devtools screen, you can edit any script, also while the script is interrupted in execution. Just edit the file and hit cmd-S on Mac or ctrl-S on Windows / Linux.

Of course, changes aren’t kept on disk unless you work locally and set up workspaces in Developer Tools, a more advanced topic.

Inspect the call stack

The call stack is great to see how many levels of functions you are deep in the JavaScript code. It also lets you move up the stack by clicking on each function name:

Call stack

Scripts Blackbox

A lot of times you work with libraries that you don’t want to « go into », you trust them, and you don’t want to see their code in the call stack, for example. As in the case above for validator.min.js, which I use for email validation.

Hope it does a good job, so I can right click on it in the call stack and hit Blackbox Script . From there it is impossible to get into that script code and you are just working on your own application code.

Use the browser developer tools to debug Node.js

Since Node.js is built on the same engine of Chrome, v8 , you can link 2 and use Chrome DevTools to inspect the execution of Node.js applications.

Open your Terminal and run

node-inspect

Then, in Chrome, type this URL: about://inspect.

node-link-browser

Click on the dedicated Open DevTools for Node link next to the Node target, and you will have access to Node.js in the DevTools browser:

node-console

Sylvie Linxe

0
0

Laisser un commentaire