Chrome Development Tools Learning notes (5)

debugging JavaScript

As JavaScript applications become more and more widespread, developers need powerful debugging tools to solve problems quickly and efficiently in the face of front-end work. The main character of our article, Chrome Devtools, provides this tool to help us reduce the pain of debugging JavaScript code.

By the way, different versions of Chrome's devtools may be slightly different, except for the digitally incrementing version number, which includes the stable version, beta, Dev development, Canary, and the originator. Chromium version of these branches. The  browser used by bloggers and the fast core of most dual-core browsers on the market are based on chromium development. From the stability aspect, the Stable>beta>dev>canary>chromium, while the updated speed is exactly the opposite chromium>canary>dev>beta>stable. If you want to use the latest devtools, then I suggest you can use the Canary version, Canary version can and existing other versions of the Chrome browser do not interfere with each other coexistence.

SOURCE panel

The Devtools source panel allows you to debug your JavaScript code, which provides a visual V8 debugger interface. We open the Devtools switch to the Source tab to see our source panel.

As with other debugging tools, on the source panel, we can see all the JavaScript scripts on the current page. and a stop/resume/step-through button that controls the JavaScript run, and a button that allows the code to pause when an exception occurs. The remainder of this article will cover the use of these features in more detail.

The Run Control button group is located at the top right of the source panel, through which you can step through our code. These buttons are:

Continue (F8): Is what we normally commonly called the release. When a breakpoint is encountered while the current execution is paused, click this button to continue executing the program until the breakpoint is hit again.

Step Over (F10): Generally we say the single step refers to this, one line of execution of the current code. A bit different from "stepping" is that when executed to a method, "Step Over" returns the execution result of the method directly, and the breakpoint executes to the next line of the current code snippet. "Step into" will enter the code inside the method. In general, we debug, the first step through, look at the output of the method, if the output is wrong, then step into the method of internal debugging.

var a;a = dosomething (); Console.info (a);

As this code above, the first line performs "Step Over" and "stepping", the effect is the same. In the second line, "Step over" skips the inside of the DoSomething method, causing the breakpoint to execute to the third row. Now look at the value of variable A, and if a returns as expected, continue debugging. If a and expected deviations, then "step into" the second line to the inside of the DoSomething method. Continue to debug with step over and walk in.

Step Into (F11): In the general code, and the "stepping" effect is the same, on the line of code executed by the method, "step into" will go to the inside of the method definition.

Step Out (SHIFT+F11): When accidentally pressed into or we need to jump out of the current method, "step out" can directly let the breakpoint back to the calling parent method. (Before knowing this, bloggers are stepping out of the way)

Toggle Breakpoint Status : You can quickly toggle the Enable/deactivate state of a breakpoint. This button can be implemented when we do not need a breakpoint for the moment and want the code to execute directly. Disabling a breakpoint does not delete the breakpoint that has been hit, and when you need to continue using the breakpoint, click again to enable the breakpoint.

In parentheses are the shortcut keys for these single-step debugging buttons, which are easier to debug with shortcut keys.

Debugging with breakpoints

Breakpoints can be temporarily stopped in a particular place, and entering a breakpoint does not terminate the execution of the program, and we can continue to do so at any time. With the Devtools breakpoint, we can debug the Javascript,dom update and the network connection.

In the source panel, open any JavaScript file. Click on the line number in front of the code, which will have a blue mark in front of the line, so that a breakpoint is hit. We can set multiple breakpoints and click on the line number of the other code. On the right side of the source panel, the "breakpoints" sidebar displays all the breakpoints that have been hit.

With the checkbox in front of the breakpoint listed in the "breakpoints" sidebar, we can enable/disable breakpoints, and the blue flag in front of the deactivated breakpoint will be lighter.

Click on the breakpoints listed in the "breakpoints" sidebar to quickly locate the line of code for the break point ~

Click the blue flag that has been hit on the breakpoint to remove the breakpoint.

Right-click on the breakpoint Blue flag to display the breakpoint related menu: Continue to Here, Remove Breakpoint, Edit breakpoint ..., Disable breakpoint.

Select "edit breakpoint..." in the right-click menu of the breakpoint to set the breakpoint as a conditional breakpoint, or you can right-click on the line number without the breakpoint and select "add Conditional breakpoint" to set the conditional breakpoint. In the input box of a conditional breakpoint, you can enter any expression that returns TRUE or false. Breakpoints only work when the expression is true to pause the current program execution. When our breakpoint hits a loop or a frequently triggered event, the conditional breakpoint can be used to avoid unnecessary pauses in the program (do not press F8 and accidentally miss the breakpoint).

The blogger took several batches of interns to see the interns. Debug programs often insert alert or console output variable content in code, accidentally commit code or release, put these debugging statements also brought up. In fact, the conditional breakpoint can be done without modifying the code file to pop the window or command line output, as long as the alert or console written to the conditions of the condition variables can be ~

When the breakpoint is triggered, the page JavaScript script execution will be paused and the page will be overwritten with a gray mask, unless we click on continue or keyboard F8 to proceed with the execution of the program.

The right "call stack" will show the current call stack, click on the different parts of the call stack, you can quickly navigate to the part of the code, we can be more convenient to trace up to the wrong part of the code.

If you want to see asynchronous JavaScript calls, such as timers and XHR events, you can tick "async"checkbox.

About "async" official documentation does not seem to be carefully said, bloggers find the code of the test, the Refreshreslist method is called by a click event, Refreshreslist method initiated an AJAX request from the server to obtain some data to display on the page. If "async" is not checked, you can only see the call stack that the Ajax request came back from, and you cannot see the process of calling Refreshreslist from the click event and executing the AJAX request. (if at first did not tick "async", enter the breakpoint after the tick is not effective, need to enter the breakpoint again, to see the effect)

There's a lot of jquery code in the call stack like that, in debugging, you might not want to go into jquery's code (after all, it's the code that we write ourselves for, after all), and we just get the returned results. We can right-click on the file list on the left and we want to add the black box JavaScript file, or in the middle of the edit area right-click, select "blackbox script" from the menu to add the selected file to the black box.

What's the effect of adding JavaScript files to a black box?

• All breakpoints in black box JavaScript are not triggered, including normal breakpoints, "pause on exceptions", and event breakpoints.
• Stepping in and out will skip the black box's JavaScript code. $ ("#test"). Empty () Such code, generally we pay more attention to its results, unless we want to know that jquery internal execution principle will be tracked into its internal bar.
• The call procedure in black box JavaScript does not appear in the call stack.

We can view and manage black box JavaScript files in the Devtools Setup Panel, and use wildcards to match black box JavaScript files.

A reasonable use of black box JavaScript allows us to focus our debugging on the code we write ourselves.

Clicking the icon in the upper-right corner of the source panel, or pressing the "esc" key in the source panel, opens a command-line area at the bottom where we can enter JavaScript code for various experiments. The input JavaScript code is scoped to the same area as the current debugger pauses. That is, when a breakpoint is triggered, the JavaScript code that we typed in the command line executes, and the effect of adding the JavaScript code to the code file is the same. Another good way to debug with the insert alert in your code ~

When writing code using the IDE or editor, we often use global search to help us locate the code, for example, to find the definition part based on the method name. In the source panel, there is a "search" tab on the edge of the command-line tool at the bottom to enable global search of all JavaScript files on the current page. It is the search for the specified string in all files listed in the File Explorer on the left, and supports regular expression queries that are more useful than ctrl+f.

One of the purposes of debugging code is to find out where the code is going wrong, Devtools provides "pause on exceptions", which pauses the execution of the code when an exception occurs. The exception breakpoint is opened by clicking on the icon at the top right, and when the icon changes, the exception breakpoint is turned on. When an exception breakpoint is turned on, you can choose to catch only the exception caught by the catch statement or catch all exceptions by ticking the "pause on caught exceptions". Note that in different browsers may "pause on caught exceptions" the same way, in the blogger's  Speed browser, is selected in the form of a checkbox, in some browsers, may be by clicking the icon again to open.

Dom Breakpoint

The right Dom breakpoints of the source panel will display the currently playing Dom breakpoint, which will be triggered when the DOM changes, and we can see the existing DOM breakpoints here, about the 3 Dom breakpoints in Devtools Note 2. Friends who want to know can take a look at Chrome development tools Learning Notes (2).

XHR Breakpoint

Below the DOM breakpoint, "XHR breakpoints" We can set breakpoints on XHR requests here to monitor page-initiated AJAX requests. In Devtools Note 4, we talked about debugging network requests through the networking tool, where the XHR breakpoints allow us to debug from the point of view of the code.

Open "XHR breakpoints", the default is another breakpoint for all XHR requests to pause, we can right-click to select "add Breakpoint"adds a breakpoint to the XHR request for the URL that contains the specified text (if the contents are empty, all XHR requests are matched, as with any xhr effect).

Event Breakpoint

Event is the heart of the JavaScript app beating and the glue that sticks everything together. Events occur when we interact with certain types of Web pages in the browser. We debug JavaScript code, which is also generally intended to solve the problem of handling code for these events. For example, a button click on the page does not work, usually we will go to the HTML file to find the corresponding element, and then go to the JavaScript file to find the corresponding event processing code, if it is a large project, this work is more time-spent. Devtools provides an event breakpoint that can be interrupted for various JavaScript events, allowing us to debug.

The event breakpoint is just below the XHR breakpoint and expands "event Listener breakpoints"can see a variety of JavaScript events, we tick the checkbox in front of the event, when the corresponding event occurs, the breakpoint will be triggered, the execution will be interrupted at the event's processing code, is not very cool~

Instant editing

In the source panel, you can edit the open JS file directly. For example, we can insert some alert or console statements to output the values of variables, modify them directly in the source panel, and press Ctrl+s to work. Devtools When we edit JavaScript immediately and save it, we will remind us that the corresponding changes will not affect the actual files, as in the previous element tool, once the page refreshes, the changes will be restored. This is a good way to not modify the code to debug it ~

Anomaly Tracking

Writing programs often encounter anomalies, such as when writing file processing, often need to find the file is not found in the case of abnormal capture, for JavaScript is the same.

When the execution of JavaScript does not match the expectations, such as clicking on a button does not have the desired effect, then most likely in the Click event throws an exception, we can open the command line, we will see some exception information, the exception of the file and line number, Click the file name and line number on the right to quickly open the file in the source panel and jump to the line of error code.

In the source panel, we can see that the code where the exception occurred is marked, and the cursor moves up to see the error message, which helps us to look at some of the more foolish code bugs.

Code formatting

In order to reduce the size of JavaScript files to speed up page loading, JavaScript files are generally compressed, the main thing to do is to remove the extra blank lines and spaces in the code, and to simplify the variable names, and some will replace the code equivalent to confuse the encrypted JavaScript code. When we debug the site, the face of these compressed code, may not start. It is common to think of using some code formatting tools to make the compressed code with appropriate indentation and wrapping to ease our understanding, Devtools provides such a code formatting tool.

By tapping the two-brace button below the source Panel edit area, you can turn on the Devtools "pretty print" function, and the JavaScript code will be converted to a more readable appearance. When we need to format JavaScript code, we don't have to go online to find it, our browser has it.

Debug Chrome Extensions

One of the advantages of chrome over other browsers is that it provides a powerful plug-in feature that gives the browser a lot of extra functionality, and simply, chrome extensions the equivalent of some extra JavaScript code on the page you're currently visiting. These additional execution codes, like the one that can be debugged through devtools. Switch to the "content scripts" tab in the file browser on the left side of the source panel to see the additional JavaScript code that is added to Chrome extensions on the current page, We can debug them like normal JavaScript code. (here in order to facilitate understanding of the chrome extensions to speak simple, the actual Chrome extensions plugin development is far from this, hope to understand.) ）

reprinted self-Technical blog http://www.cc-lab.cn/chrome-dev-tools-5/

Finish

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Chrome Development Tools Learning notes (5)