This is the first day of my participation in the August Challenge. For details, see:August is more challenging

Bug

When we develop and debug, the goal is to find and eliminate bugs.

The word “Bug” comes from an American scientist who found a Bug stuck in a relay while debugging a machine. She gave it the name “Bug”, which is still used today.

Chrome devtools

Right-click on a web page – check, or F12 to open Chrome DevTools, which has multiple debug panels.

The Elements panel

Using the Elements panel, you can view the HTML information of the site by clicking the small button in the upper left corner (Ctrl+ Shift +C) to select and view the style information of the Elements. When debugging web pages, you can modify HTML and CSS directly in the Elements panel. Real-time preview is convenient for debugging.

For some pseudo-class styles, you can also force the pseudo-class activation by selecting it in the panel.

Sometimes there are too many styles and we can simply search for the style name we are looking for in the computed TAB and click on the corresponding style section.

The Console panel

The one I use most often for daily debugging is console.log, and the console panel actually has a number of useful methods. Different printing methods show different colors, which makes it easier to see information when debugging. Common examples are:

console.warn
console.error
console.debug
console.info
console.table
Copy the code

At the same time, different data types display different colors in the panel, to help us know whether the output is a number or a string. Placeholders can also be used in the panel, and the style placeholder %c can add an interesting tidbit to the log.

Sources panel

In debugging, we can see the source code of the web page through the Sources panel, and in the toolbar on the right, we can view the listener, breakpoint, scope, call stack and so on. When you enter a breakpoint, you can see the value by mouthing over a variable, a bit like debugging code from a backend IDE. In addition, you can add a breakpoint by clicking in front of the line number, or you can write debugger directly in the program.

In Sources, you can also add little scripts you write yourself, so-called code snippets that run on any page. Scripts and plug-ins installed on the browser can be seen in the directory bar.

Since the Sources panel can see the source code directly, it raises the issue of security, and what we usually see when we open the site is generally processed. Some are compressed and confused, replacing variable names and compressed into a single line, which can be formatted by clicking the {} button, while others are not visible.

To keep the client-side code readable and debuggable during debugging, you can use Source Maps to map the Source code to the compiled code. The Source map file is generated during packaging. Before going online, the file is uploaded to the error monitoring platform on the Intranet. When an error occurs, you can see the corresponding mapping.

There’s a lot of detail about this section, and there’s a link to Source Maps standards and articles.

The Performance panel

The Performance panel displays various events in the Web lifecycle, including FPS, CPU, and NET information at each point in time, as well as the Web thread panel and statistics panel. By analyzing the information, you can find the key points that affect the performance of the web page and optimize accordingly.

The Network panel

In the Network panel, you can view all Network request information, perform packet capture, prohibit loading resources from cache, limit bandwidth, simulate weak Network environment, and so on. By selecting a network request, you can view the details of the request, such as request line, request header, response line, response header, response body, and so on. Visually see the original content of the packet, so you can rule out if your webpage is rendering a bug.

Application

Storage, database, and Caches can be checked and modified in the Application panel. In storage, you can click Clear Site Data to clear the data of this website.

Mobile TERMINAL H5 debugging

In general, you can simulate a variety of mobile devices using the upper left button of DevTools.

Real machine commissioning

Real machine debugging, if the use of wired connection is very inconvenient, it is recommended to scan the code directly. Fehelper plug-in (recommended) can be used to generate a QR code for the website. In the LAN, you can scan the code directly with your mobile phone to view the website.

Debug using the agent tool

Charles mobile packet capture tool, Progress packet capture tool, etc. HTTPS related websites need to install certificates.

conclusion

In fact, there is a final debugging method: yellow duck

The way to do this is to walk your code through a little yellow duck, or a colleague or girlfriend, and figure out the problem step by step.

Time is limited, explore more, learn more front-end debugging knowledge can save a lot of time, improve efficiency. As front-end technology evolves, there will be more and more ways to debug, and Chrome has added panels like Lighthouse to help with debugging. There are many, many interesting features to explore in browser debugging tools. Here’s a link to the full Chrome DevTools documentation

The lesson was taught by the bald caped teacher, and ALL I can say is that the bald teacher was very good