Chrome development tools learning notes (5) and chrome learning notes

Chrome development tools learning notes (5) and chrome learning notes
Debug JavaScript

As JavaScript applications become more and more widely used, developers need powerful debugging tools to quickly and effectively solve problems in the face of front-end work. Chrome DevTools, the main character of our article, provides such a tool to help us reduce the pain of debugging JavaScript code.

By the way, the DevTools of Chrome browsers of different versions may be slightly different, except for the version numbers that increase progressively, chrome includes the official Stable version, Beta version, Dev development version, Canary version, and originator Chromium version. The  speedy browser used by the blogger and the extreme core of most dual-core browsers on the market are all developed based on Chromium. In terms of stability, Stable> Beta> Dev> Canary> Chromium, while the update speed is the opposite: Chromium> Canary> Dev> Beta> Stable. If you want to use the latest DevTools, we recommend that you use the Canary version, which can coexist with other existing Chrome versions.

Source panel

The Source panel of DevTools allows you to debug your JavaScript code. It provides a visual V8 debugger interface. Switch DevTools to the Source tab to view the Source panel.

Like other debugging tools, on the Source panel, we can see all the JavaScript scripts on the current page. It also controls the stop/Continue/step button for JavaScript running, and the button that can be used to suspend code when an exception occurs. The rest of this article will detail the use of these features.

The running control button group is located in the upper-right corner of the Source panel. You can use them to debug our code in one step. These buttons are:

Continue (F8): This is what we usually call "allow. When a breakpoint is paused, click this button to continue executing the program until the breakpoint is paused again.

STEP (F10): Generally, a single step refers to the execution of the current Code in one row. Unlike step-by-step, when a method is executed, step-by-step directly returns the execution result of the method, and the breakpoint is executed to the next line of the current Code segment. "Step" will enter the code inside the method. During debugging, you can check the method output first. If the output is incorrect, you can debug the method.

var a;a = doSomeThing();console.info(a);

As shown in the above Code, the first line of "step through" and "step into" will have the same effect. In the second row, "Step through" will directly skip the inside of the doSomeThing method, so that the breakpoint is executed to the third row. Check the value of variable a. If a returns the same result as expected, continue debugging. If there is a deviation between a and expectation, "Step" to the inside of the doSomeThing method in the second line. Continue debugging through "Step by Step" and "Step by Step.

Step into (F11): In general code, the effect is the same as that of "Step by Step". On the code line of method execution, "Step by Step" will enter the method definition.

Step-out (Shift + F11): When you accidentally step in or we need to jump out of the current method, you can get the breakpoint back to the parent method of the call. (In the past, bloggers went out step by step)

Switch breakpoint status: You can quickly switch the enabled/disabled status of a breakpoint. You can use this button to execute code without breakpoint. Disabling a breakpoint does not delete a breakpoint. When you need to continue using the breakpoint, click it again to enable the breakpoint.

The shortcut keys of these single-step debugging buttons are in brackets. You can use the shortcut keys to facilitate debugging.

Debug through breakpoint

The breakpoint can temporarily stop the program at a specific place. The breakpoint does not terminate the program execution, and we can continue to execute the program at any time. Through the breakpoint of DevTools, We can debug JavaScript, DOM updates, and network connections.

Open any JavaScript file on the Source panel. Click the row number in front of the code, and a blue mark will appear in front of the line, thus hitting a breakpoint. You can set multiple breakpoints and click the line number of other codes. On the Right of the Source panel, all Breakpoints are displayed in the Breakpoints sidebar.

With the checkbox in front of the breakpoint listed in the "Breakpoints" sidebar, we can enable/disable the breakpoint. The blue mark in front of the disabled breakpoint will fade.

Click the breakpoint listed in the "Breakpoints" sidebar to quickly locate the code line of the breakpoint ~

Click the blue icon of the breakpoint to remove the breakpoint.

Right-click the breakpoint blue icon, and the breakpoint-related menus are displayed: Continue to here, Remove breakpoint, Edit breakpoint..., and Disable breakpoint.

Right-click the breakpoint and choose Edit breakpoint... you can set a Breakpoint as a Conditional Breakpoint. You can also right-click a row without a Breakpoint and select "Add Conditional Breakpoint" to set a Conditional Breakpoint. In the input box of the condition breakpoint, you can enter any expressions that return true or false. The breakpoint takes effect only when the expression is true. When our breakpoint is triggered in a loop or frequently triggered event, the conditional breakpoint can avoid unnecessary pause of the Program (you don't need to press f8. you are afraid to accidentally miss the breakpoint ).

The blogger often inserts alert or console variables in the code to view the intern debugging program. When you accidentally submit the code or release it, these debugging statements are also taken. In fact, you do not need to modify the code file to pop up the window or output the command line through the condition breakpoint. You only need to write alert or console to the condition variable ~

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

The current Call Stack is displayed in the "Call Stack" on the right. Click different parts of the Call Stack to quickly locate the code, we can easily trace up some codes with errors.

To view Asynchronous JavaScript calls, such as timer and XHR events, check Async checkbox.

The official Async documentation does not seem to be detailed. The blogger found the code for testing. The refreshResList method in the figure is called by a click event, the refreshResList method initiates an ajax request to retrieve some data from the server and display it to the page. If "Async" is not selected, only the call stack returned from the ajax request is displayed. The refreshResList called from the click event is not displayed, and then the ajax request is executed. (If "Async" is not selected at the beginning, it does not work until the breakpoint is clicked. You need to enter the breakpoint again to see the effect)

There are a lot of jQuery code in the call stack of the image. During debugging, you may not want to enter the jQuery code (after all, we usually write our own code for debugging ), instead, we only get the returned results. You can right-click the file list on the left and right-click the JavaScript file that we want to add to the black box, or right-click the editing area in the middle, select "BlackBox Script" from the menu to add the selected file to the Black Box.

What is the effect of adding a JavaScript file to the black box?

• All Breakpoints in black box JavaScript are not triggered, including normal breakpoints, pauses caused by "Pause on exceptions", and event breakpoints.
• The Black Box JavaScript code will be skipped after you step through. $ ("# Test"). empty () code. Generally, we pay more attention to its results, unless we want to know the execution principles inside jQuery, We will track the results into it.
• The call process in the black box JavaScript is not displayed in the call stack.

You can view and manage the Black Box JavaScript file on the settings panel of DevTools, and use wildcards to match the black box JavaScript file.

The rational use of the Black Box JavaScript function allows us to focus more on our own code debugging.

Click the icon in the upper-right corner of the Source panel, or press the "ESC" key on the Source panel to open a command line area at the bottom. We can enter JavaScript code to perform various experiments. The scope of the entered JavaScript code is the same as that of the Area paused by the current debugger. That is to say, when a breakpoint is triggered, the JavaScript code we typed in the command line is executed in the same way as adding the JavaScript code to the code file. Another good method is to insert alert into the code for debugging ~

When writing code using the IDE or editor, we often use global search to help us locate the Code, for example, finding the definition part based on the method name. On the Source panel, there is a "Search" tab on the edge of the command line tool at the bottom, which enables global Search for all JavaScript files on the current page. In fact, you can search for the specified string in all the files listed in the file browsing area on the left, and support regular expression query, which is much easier to use than Ctrl + F.

One of the purposes of code debugging is to find out where code Exceptions occur. DevTools provides "Pause on Exceptions", that is, to Pause code execution when an exception occurs. To enable an exception breakpoint, click the icon in the upper-right corner. When the icon changes to, the exception breakpoint is enabled. When an exception breakpoint is enabled, you can select "Pause On Caught Exceptions" to capture only Exceptions not Caught by the catch statement or all Exceptions. Note that different browsers may use the "Pause On Caught limits" function in different ways. The  speed browser of the blogger is selected in the form of a checkbox. On Some browsers, it may be enabled by clicking the icon again.

DOM breakpoint

The right DOM Breakpoints on the Source panel displays the currently marked DOM breakpoint, which is triggered when the DOM changes. We can view the existing DOM breakpoint here, for details about the three DOM breakpoints in DevTools Note 2, go to Chrome development tools learning notes (2.

XHR breakpoint

At the bottom of the DOM breakpoint, "XHR Breakpoints" can be used to set a breakpoint for XHR requests to monitor ajax requests initiated on the page. In DevTools note 4, we talked about debugging NetWork requests through the NetWork tool. The XHR breakpoint here allows us to debug the code.

Open XHR Breakpoints. By default, another breakpoint is paused for all XHR requests, you can right-click "Add breakpoint" to Add a breakpoint for an XHR request containing a URL of the specified text. (If the entered content is blank, it will match all XHR requests, same effect as Any XHR ).

Event breakpoint

Events are the heart of JavaScript applications and the glue that sticks everything together. When we interact with some types of Web pages in the browser, the event occurs. We debug JavaScript code to solve the problem of code processing for these events. For example, if a button on the page does not work, we usually find the corresponding elements in the HTML file, and then find the corresponding event processing code in the JavaScript file. If it is a large project, this is a relatively time-consuming task. DevTools provides an event breakpoint that can interrupt various JavaScript events for debugging.

The Event breakpoint is under the XHR breakpoint. Expand Event Listener Breakpoints to view various JavaScript events. We select the checkbox before the Event to trigger the breakpoint when the corresponding Event occurs, whether the execution interruption is cool ~

Instant editing

On the Source panel, you can directly edit the opened js file. For example, We can insert some alert or console statements to output the value of the variable and directly modify it in the Source panel. pressing Ctrl + S will take effect. After editing and saving JavaScript in real time, DevTools will remind us of the corresponding modifications and will not affect the actual files. It is the same as the Element tool mentioned earlier. Once the page is refreshed, changes will be restored. This is a good way to debug without modifying the code ~

Exception tracking

Exceptions often occur when writing a program. For example, when writing a file, you often need to capture exceptions when the file cannot be found. The same is true for JavaScript.

When JavaScript execution is not as expected, for example, clicking a button does not have the desired effect, it is very likely that an exception is thrown in the click event. We can open the command line, you will see some exception information, abnormal files and row numbers, click the file name and row number on the right side to quickly open the corresponding file in the Source panel and jump to the wrong line of code.

On the Source panel, we can see that the Code with an exception is marked, and the cursor moves up to see the error information, which helps us to see silly code bugs at a glance.

Code formatting

To reduce the size of JavaScript files and speed up page loading, JavaScript files are generally compressed. compression is mainly used to remove unnecessary blank lines and spaces in the Code and simplify variable names, some will also replace the code to confuse the encrypted JavaScript code. When we debug a website, we may not be able to cope with the compressed code. We usually want to use some code formatting tools to add appropriate indentation and line breaks to the compressed code for our understanding. DevTools provides such a code formatting tool.

Click the two parentheses at the bottom of the editing area of the Source panel to enable the "Pretty Print" function of DevTools. The JavaScript code is displayed in a more readable way. When we urgently need to format JavaScript code, we don't need to go online to find it. Our browser has it.

Debug Chrome Extensions

One of the advantages of Chrome compared with other browsers is that it provides powerful plug-ins. Plug-ins can bring many additional features to the browser. In simple terms, chrome Extensions is equivalent to executing some additional JavaScript code on the currently accessed page. These extra code can also be debugged through DevTools. Switch to the "Content scripts" tab in the file browser on the left of the Source panel, and you will be able to see the additional JavaScript code added to Chrome Extensions on the current page, we can debug them like debugging JavaScript code. (Chrome Extensions is easy to understand here. The actual Chrome Extensions plug-in development is far from this. I hope you can understand it .)

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

(End)

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.