Best use of Chrome developer tools

Debugging Javascript Like a Pro

Are you still using console.log for debugging when your code doesn’t perform as expected? If so, this article is for you.

My purpose in writing this article is to give you an insight into the efficient tools Chrome development tools provide to enable you to debug Javascript code better and faster.

This article mainly tells the following contents:

• Set breakpoints to debug specific lines of code
• Look at the call stack
• Pause/resume script execution
• Set expression
• Productivity tips and tricks for developing tools

Debug the runtime code

When the code is buggy or doesn’t perform as expected, we usually look at the Sources TAB in the developer tools, and we’ll take a closer look at this feature module in different scenarios.

The breakpoint

Before reading this article, you were probably used to debugging code by printing a value on the console. But I want to introduce you to a more efficient approach, one that goes deeper into your code: breakpoints.

Setting breakpoints is usually the first step in the debugging process. While the built-in development tools in most browsers today allow you to debug the page you’re viewing and stop executing code on a particular line or statement, in this article we’ll focus on the Chrome developer tools.

What is a breakpoint?

Often, you might want to stop executing code so that you can look at a particular context line by line.

Once the code stops at the breakpoint, we can debug by accessing the scope, looking at the call stack, and even changing the code at run time.

How do I set breakpoints?

Since it’s not important to debug which front-end technology you use, to make it easier to explain breakpoints to you, I’ll debug an Angular project for training.

• First, open the development tool and go toSourcesTAB
• Then, open the file we want to debug
• Once the file is open, we can set a breakpoint by clicking on the line of code we want to stop

Tip: On a Mac, use the shortcut key to ⌘ + O to open the file selector where you can find the file you need to debug. On Windows, you can use CTRL + O

As shown in the figure above, breakpoints can be set more deeply on a line of code, such as different statements within a line of code.

We set three breakpoints:

• The first breakpoint stops execution when the code is defined
• The second breakpoint will be atpriceReceivedStop before the function is executed
• The third break point will be atpriceReceivedStop immediately after it is called, so we can also check the return value of the arrow function

When the arrow function is called, execution stops, and the right pane Scope shows the current context and allows us to access all the values we want to view.

As shown in the figure below, we can see the value of the variable price.

In the figure below, once priceReceived is executed, a third breakpoint is used.

In the right pane, you can use Return Value to see the Return value of an anonymous function.

Temporarily cancel breakpoint

Scenario: You set a bunch of breakpoints in your code.

It is common to refresh the page multiple times during debugging.

The code you are currently debugging can have various breakpoints, sometimes hundreds of them. These hundreds of breakpoints can waste a lot of your time.

In this case, you can temporarily pause all breakpoint execution by toggling the icon shown in the following image:

Stop on execution error

Scenario: Your code execution produces an error, but you don’t want to set a breakpoint because you don’t know when an error will be thrown.

Throw errors in your code so you can see what’s wrong with your code.

Conditional breakpoints

As the name implies, a conditional breakpoint is a breakpoint that is triggered only if the condition is true.

For example, in the example above, the user can enter non-numeric values in a text area. Because of JS compatibility, NaN is only displayed and not thrown.

Scenario: Your code is more complex than the code above, and there is no way to determine when NaN occurs.

Of course, you can set a breakpoint, but replicating the error is not easy and can end up taking half an hour to execute the code. In this case, you can use conditional breakpoints and stop executing code only when NaN occurs.

The diagram below:

• Right-click the line of code where you want to add the breakpoint
• Click Add Conditional Breakpoint…
• Add a valid JS expression. Of course, you can refer to the arguments X and y when calling the expression
• A breakpoint is triggered when the expression is true

Step through the code

To get the most out of Dev Tools, it’s worth spending a little time learning how development Tools help us step through code quickly without having to set breakpoints on every line.

Use the Navigator in Dev Tools to execute code sequentially, line by line.

I will describe the difference between Step over Next function call and Step in the following sections. When debugging asynchronous code, clicking the Step button moves to the next line in chronological order.

Skip the next function call

The Step over Next Function Call button also executes the code sequentially, but does not enter the function call. That is, the function call will be skipped, and the debugger will not stop in the function unless you set a breakpoint there.

If you look closely at the figure above, you can see that multiplyBy and renderToDOM are not executed inside the function like Step.

Go to the next function call

The Step Into Next Function Call button has changed since Chrome 68. It is similar to Step mentioned above. The difference is that when you enter asynchronous code, it stops in asynchronous code, rather than code that runs in chronological order

As shown above: In chronological order, line 32 should have been running, but it wasn’t. The debugger waits two seconds before moving to line 29

• Exit function call

Assuming that when debugging code, you don’t want to go inside a function, Step Out of function call allows you to exit the function and stop on the next line after the function call.

What happened in the picture above?

• The code stops at a breakpoint on line 36
• And then you jump out of the functionrenderToDOM
• The debugger moves straight to line 29 and skipsrenderToDOMThe rest of the function

Global variables and immediate output

Sometimes, it can be useful to store some values globally (such as component classes, large arrays, or complex objects).

For example, when you want to pass in different parameters to a component’s method, adding those parameters to the global scope during debugging can save a lot of time.

In the figure above, I store the array [previous, current] as a global variable. The developer tool automatically assigns a variable named temp{n} based on the number of previously saved variables.

As shown above, the variable is named temp2, which you can use in the console because it is now a global variable!

Instant Output is a feature released in Chrome 68, where development tools allow you to display the results of your execution in the console as you type code.

If you look closely at the figure above, I didn’t press Enter when I mapped the saved variables to the string array, but the result is immediately displayed on the next line.

Look at the call stack

Looking at the call stack is one of the most useful tools that developer tools provide: you can not only jump back and forth in the functions that call them, but you can also examine their scope at each step.

Suppose we have a simple page and a script to enter a number and render the number multiplied by 10 on the page. We’ll call two functions: one to multiply and one to render the results to the page.

As shown above, we can browse the scope of functions by simply clicking on their names in the Call Stack pane.

If you look closely, the scope remains every time we jump from one function call to another, and we can analyze each step here!

The Blackbox script is used to flatten the stack

The Blackboxing script filters the call stack by excluding specific scripts from the stack or scripts that match certain patterns.

For example, if I’m only interested in debugging code in userland 99% of the time, I can add a mode in Blackbox that filters out all scripts in the node_modules folder.

To filter a script through Blackbox, there are two ways:

• Right click on theSourcesJS Script in the TAB, and then click “Blackbox Script”
• Go to the Chrome Settings page, then go to Blackboxing and clickAdd Pattern...And enter the re you want to add to Blackbox, which is useful when you want to filter a lot of scripts.

Monitor expression

By monitoring expressions, you can define Javascript statements and display the results of those statements in the developer tool run. This is a particularly interesting tool because you can write any virtual case you want, as long as it’s a valid Javascript expression.

For example, you can write an expression that always results in true, and when the expression results in false, you can see that there is a problem with the current running state.

There is one problem to pay attention to:

• When we debug using breakpoints, the monitor expression is executed immediately without a page refresh
• If the code is running properly, you need to manually click the refresh button

conclusion

Browser developer tools are great tools for debugging complex code. Sometimes you need to go further than console.log, and the functionality mentioned above will provide a debugging experience that goes deep into the code. These tools take some practice to fully master, so if you’re not familiar with some of the features, don’t give up and stick with them.

data

Here are some resources to help you fully grasp all the features offered by development tools:

• Start debugging JavaScript using Chrome DevTools
• Console Overview

Welcome to reprint, remember to indicate the author and source oh ~~