Now Chrome is undoubtedly the most popular with the front-end tool, cause a large number of applications in addition to the interface is simple and plug-in, a good code specification support, powerful V8 interpreter, but also because of the Chrome developer tools provide a lot of convenient functions, convenient our front debug code, we in daily development is more and more inseparable from the Chrome, Proficiency in Chrome debugging may also be a benchmark for the level of front-end technology.

There are many articles about Chrome debugging techniques. This article combines my own development experience and hopes to talk about these features again from the perspective of practical application. I also hope to help and inspire everyone.

Better reading experience >>

Common Shortcut keys

CTRL + P to locate the VueJS library file:

CTRL +shif+ O file to locate member functions, following to locate VueJS nextTick interface:

Snippets code at any time

Chrome provides a snippets bar on the Souces page, where we can write JS code at any time and the results are printed to the console. The code is saved globally and can be viewed or run on any page, including new tabs.

We no longer need to create a new HTML page to run a small piece of JS code. The convenience of Snippets is that you just need to open Chrome to write A JS code that can run on any page, and as anyone who has ever used Snippets knows, the Snippets editor is comparable to sublime Text.

On one project, I had to import more than 100 pages of Word documents into the page. The HTML structure of the page is as follows:

 class="help-page_row">
     class="help-page_title">title
     class="help-page_desc">paragraph

     class="help-page_desc">paragraph


Copy the code

Combining 100 + pages of content into the HTML structure above was too time-consuming to be practical by hand, so I decided to use JS to parse out the title and paragraph of the document content and wrap it in HTML.

Since you don’t need view support, it’s best to write this code in Snippets. After a few debugging changes, the result is as follows:

Finally, copy the contents of the Word document to the snippets, perform the parsing function, and print the final parsed HTML to the console:

The copy interface of the console can be used in Snippets, and it is easier to copy the results of the parsing directly to the clipboard

When we use Snippets to do this kind of lightweight work, we don’t need to make our code readable and maintainable. Our code just needs to work in most scenarios.

But for most scenarios, the code needs to be debugged repeatedly. The most useful thing about Snippets is that they’re always written, always debugged, always modified!

Copy Format copy

During project development, we may need to copy background data locally for debugging as local data.

If unformatted JSON data is returned in the background, it is inevitable that you will have to manually modify the data during local debugging. If the JSON data is not formatted in a good way, it will be very difficult to modify it.

When it comes to JSON formatting, the first thing that comes to mind is the formatting functionality of json.stringify, such as the indentation of four Spaces:

JSON.stringify({name: 'lxjwlt'}, null, 4);
Copy the code

Writing this code every time you format JSON data is too much of a hassle, we can use the Copy interface of the Chrome Console to solve this problem:

  1. Right-click a request item and choose Copy Response to Copy the Response content
  2. The copy interface is used on the command line to process data
  3. Get formatted JSON data

The copy interface can copy any data, not just objects. It takes advantage of the ability of copy to beautify the data as it copies arrays or objects

The iframe debugging

If we use the Webpack server tool webpack-dev-server to access the development page of the project, we will see that the development page is embedded in the iframe for rendering.

Since the default context of the Chrome console is window.top, the development page embedded with iframe cannot be manipulated directly from the console. If we want to DOM manipulate the page in the iframe, or execute the library API, we first get the context of the iframe using contentWindow, and then use the with statement to debug it:

// HTML // console with (document.getelementById ('iframe').contentWindow) {inspect(document.body); new Vue({ /* ... * /}); // do something... }Copy the code

The above method can be used on any browser, but if we are using Chrome, the Chrome Console context switch feature is much more convenient:

We switch the context to the IFrame, and all the console code is executed based on the iframe context. If you use webpack-dev-server for debugging, you’ll appreciate this feature.

Debug is useless?

The Chrome console provides the Debug interface, which allows you to pass in a function where the debugger will automatically debug breakpoints the next time the function is executed.

We can set breakpoints in the code for debugging, why to set debug, is to abandon the mouse with command line installation force?

In my opinion, the debug function also provides a location function, which allows us to find the specified function quickly. The following shows how to debug the VueJS data driver and how to find the VueJS data driven code entry.

As we all know, VueJS is data-driven by encapsulating getters and setters of data through defineProperty method. In this encapsulation, data changes drive view synchronous modification. If we want to explore the data-driven nature of VueJS, we first need to find a place to encapsulate getters and setters, which we can do through the Debug interface. The following uses the getter method as an example.

First we know that the data in the VueJS instance is the value in the _data attribute of the mapping:

var vm = new Vue({
    data: {
        name: 'lxjwlt'
    }
});

vm.name === vm._data.name; // true
Copy the code

So the data we’re looking for is actually in the _data property of the VueJS instance. Next we get the getter for the data descriptor by getOwnPropertyDescriptor:

Object.getOwnPropertyDescriptor(vm._data, "name").get;
Copy the code

Having found the getter function, we can debug it using the Debug interface:


debug(Object.getOwnPropertyDescriptor(vm._data, "name").get)
Copy the code

Thus, when we get vm.name data, the getter function for that data is automatically fired, which triggers breakpoint debugging and automatically locates the function:

To debug or locate public apis later, try Chrome’s Debug interface!

Conditional breakpoint

In Chrome, we can set expressions for breakpoints. Breakpoint debugging only takes effect when the expression is true, which is a conditional breakpoint.

With conditional breakpoints, we can more precisely control the timing of breakpoints when debugging code, especially when a piece of code will be run repeatedly. Conditional breakpoints can skip most cases and only focus on the desired situation. In addition to this, conditional breakpoint debugging has another use.

In breakpoint debugging, we often check the execution state of the current code. If the operation is tedious, we can use conditional breakpoints to add automatic operations to help reduce some of the work.

For example, if we want to view a DOM element after a breakpoint has occurred, the breakpoint condition could be written like this:

// Break the DOM element when it meets a condition and look at the element elem. HasAttribute ('class') && inspect(elem);Copy the code

If we do not know the return value of the operation, we can force the operation to return true without affecting the conditional judgment of the breakpoint:

elem.hasAttribute('class') && (inspect(elem) || true);
Copy the code

Or the line may write:

if (elem.hasAttribute('class')) {inspect(elem); true; }Copy the code

For example, in VueJS debugging, we often need to know the current state of VueJS instance, so every time the breakpoint debugging is triggered, we can use the clear interface to clear the console history output, and then print the current state of VueJS instance:

vm.sum > 4 && (clear() || vm.$log() || true);
Copy the code

If a variable is defined in a conditional breakpoint, it is defined in the global scope, that is, on the Window object

Async debugging

The Async mode of the Chrome debugger is designed to debug asynchronous functions.

When Promise is widely used today, we all know that the callback of Promise is executed asynchronously. Before the Async mode is started, the callback function itself is only recorded in the transfer stack, and we cannot find the order of code execution, which brings us great difficulties in debugging. Async mode solves this problem:

After Async mode is enabled, the previous call stack of asynchronous functions is recorded, and the code execution state in the call stack is also preserved.

Read more

  • Chrome Console Reference
  • Chrome Command Line Reference
  • Debugging Asynchronous JavaScript with Chrome DevTools
  • Chrome DevTools Code Snippets