Chrome Developer Tools Incomplete Guide (second, advanced article)

　　In the previous article, we introduced the basic function, this time to share the most useful panel Sourcesin chrome development tools. The Sources panel is almost the most common chrome feature panel I've used, and it's the main function panel that I see To solve general problems. Usually as long as the development has encountered JS error or other code problems, after reviewing their own code and nothing, I will first open Sources for JS Breakpoint debugging, and it can almost solve my 80% of the code problem. JS Breakpoint This feature is exciting, in no JS breakpoint function, only in IE (evil IE) by the Alert pop-up window debugging JS Code of the era (special alert an object will not talk to you at all), such a development environment for the front-end programmer is simply a nightmare. This article will explain the specific use of Sources , to help you in the development process to debug the JS code happily, rather than because it is crazy. First open the F12 developer tool to switch to the Sources panel:

　　Sources function Panel is a resource panel, he is mainly divided into four parts, four parts are not independent, they are interrelated, interaction together to achieve an important function: monitoring JS in the implementation of the activities of the period. In short, it's a breakpoint.

　　First of all we look at area 1, its function is similar to the resources panel, mainly to display Web page loaded script files: such as CSS, JS and other resource files (it does not contain static resource files such as cookie,img).

　　Area 1 the navigation bar has three tab switch options, they have different domain names and environment of JS and CSS files, we first to explain Sources function of the (Resource) option:

　　S ources: The static resource file that contains the project. Double-click the selected file, the contents of the file will be displayed in Region 2, if you select the JS file, then you can be in the area 2 Click the line number for breakpoint debugging, as long as JS execution to the line you marked, it will stop execution down and wait for your command:

　　

　　From the time you can see the changes in each area when JS executes to the breakpoint, first, the breakpoints record information in Region 3 is highlighted, and then the private and public variable information is listed in the Scope option in Region 4, In this way, I can be very intuitive to know, at this moment JS's execution state. Similarly, you can put the mouse in the area 2 kinds of a variable, the browser will pop up a small box, the box is you hover over the variable all the information:

then, you can press F10 followed by JS to follow the path of the step-by-step, if you encounter a function containing another function, then you can press F11 into a function to observe its code execution activities. You can also track the JS code by clicking on The individual icons at the bottom of area 1. But I suggest you use shortcut keys, so the name of meaning, because it is relatively fast and convenient. But how to use it completely according to personal habits. is the function of each button.

　　Numbers in the blue circle, which represent:

　　1. Stop Breakpoint Debugging

2, do not jump into the function, continue to execute the next line of code (F10)

3, jump into the function (F11)

4. Jump out of the function that executes

5, disable all breakpoints, do not do any debugging

6, the program runs when encountered an exception when the switch is interrupted

　　Next in the Zone 4 switch to the Watch Expressions option, it is to add an expression for the current breakpoint, so that every time a breakpoint down a step will execute the JS code you write down. It is important to note that this feature must be used with caution, as this may result in the monitoring code snippet that you write is constantly being executed.

　　To avoid repetitive execution of your debug code, we can output the information at the current breakpoint directly on the console console at the time of debugging (recommended). To verify that we have the current breakpoint environment in the console panel, we can compare this value change before and after the breakpoint execution.

If you think it would be a hassle to see a variable in a breakpoint when it has to be borrowed from the console panel output, then you can update the latest version of Chrome, which has solved this annoyance for us. In order to facilitate the debugging of developers, at this point Google has done the ultimate, just a few days after the update of Chrome, stewed accidentally found the breakpoint when the monitoring environment variables of another way, this way is very clear, in the breakpoint debugging, Zone 2 will automatically display the value of each variable, This value is updated every time the code goes down. This allows developers to be almost at a glance at the current environment variables. (This feature has a small flaw, that is, you can't see the array or the object's specific indexes and values, but I'm sure Google will improve it.) )

　　

　　when your project has been online and a bug has been fixed and you can't see the effect on it after you fix it, you can change the code on the line and then see the effect directly in the browser. This effect is often the most direct, this method can also help you eliminate the trouble of frequent verification release, after all, as the front-end code farmers you will also be sure to hear the backstage (usually the background release) Big Brother complained: "XXX, Test passed no, do not appear ha, released a very troublesome!" ”。 In Chrome, you can verify that your code is available online by simply modifying it in the area of 2 . Stewed here is just one of the uses of this feature. The rest is based on the ingenuity of all of you .

　　Even at breakpoints, you can edit the code, and when you press Ctrl+s, you'll see that the background of area 2 is changed from white to light, and the breakpoint starts executing again.

　　Back to Zone 1, theContent script option in the open bread with some third-party plug-ins or the browser's own JS code, often it is ignored, in fact, it has little effect. We can look more closely at the Snippets option. Do you remember the style introduced in the basic article? In the inside we can edit the interface CSS code and immediately see their mapping effect, in the same way, in sinppets , we can also edit (rewrite) JS code snippet. These fragments are actually equivalent to your JS file, the difference is that the local JS file is edited in the editor, and here, you are written in the browser. These snippets will neither disappear nor execute when the browser refreshes, unless you manually execute it. It can exist in your local browser, even if you close the browser and open it again when it is still there. Its main role can make it easy for us to write test code for some projects, you know, if you write this code on the editor, you have to add comment symbols to them at the time of publishing, or delete them manually, and writing on the browser doesn't have to be tedious.

Right-click on the Snippets option in the blanks and choose the new option that pops up, create a file of your own, and then edit it in Region 2 .

　　Snippets is very powerful, and many of its hidden features have yet to be explored. Currently used in stew it is in the memory of debugging fragments, unit tests, a small amount of function code writing function.

　　Finally, we look at the time-rich JS in the monitoring function, as described in the previous article,Sources panel and Elements panels have the function of monitoring events, and Sources features richer and more powerful. This part of its functionality is concentrated in zone 3 . I thought of an example to observe its effect.

　　From top to bottom, the meaning of the numbers in the Purple Circle:

　　1, the debt stack at the breakpoint, that is, from the function, step by step search call to his function name. For example:

function A () {   B ();} Function B () {   C ();   } Function C () {  //At the breakpoint, view the order of the call stack   }a->b->c.call stack from top to bottom is the CBA

2, in zone 2 , your breakpoint debugging information. When a breakpoint is executed, the corresponding information is highlighted, and double-clicking the information can be quickly located in Area 2 .

3. Added DOM monitoring information.

4, click + and enter the URL contains a string to listen to the URL of the Ajax request, the input content is equivalent to the URL of the filter. If you do not fill in anything, then listen to all XHR requests. Once the XHR call is triggered, it is interrupted at Request.send ().

5. Add various types of breakpoint information to the Web page. If you select an item in mouse (click), when you start this action on a webpage (clicking anywhere on the page), your browser is the immediate breakpoint to monitor the event.

　It is worth repeating again that sources is the most commonly used and most useful feature panel in general functional development, and many of its features are very helpful for us to develop front-end projects. Today in the web2.0 era, I do not recommend the behavior of writing debugging information in your own code, as this will make your development cumbersome. Chrome development tools Give us the power we need to take advantage of. This is the end of this article, although a bit cumbersome, but finally basically described the use of brine cooking experience and ideas, hope to help you. If you feel good about it, please recommend this article and continue to follow the stew in the blog. In the next article I'll show you how to debug performance in chrome development tools.

Chrome Developer Tools Incomplete Guide (second, advanced article)