In daily debugging problems, I believe many of us use the console to troubleshoot related issues. Although problems can be identified, sometimes their efficiency is not high. This article mainly explains about breakpoints and some daily debugging skills, so that you can apply different debugging methods in different front-end scenarios in future debugging problems, and double your efficiency in solving problems
The source panel is a place we often use for breakpoint debugging. We can first get a general idea of what it looks like and what functions it has
Left block: Contains 5 functional blocks such as Page, Overrides, Snippets, etc. Page can view all resources loaded on the webpage
• Middle block: You can view and edit resource files, as well as view image type files; At the same time, breakpoints and other related operations can be performed on the left side of its file
Right block: the area for breakpoint debugging, where breakpoint operations such as starting and next can be performed, and information such as variable values and call stacks can be viewed during breakpoint debugging
When the area displaying developer tools is too small, it will adaptively adjust the layout
The most common thing we use in our daily lives may be line breakpoints, but sometimes using them to debug problems is not the most efficient. Chrome also includes other breakpoint methods, which can be efficiently debugged by applying different breakpoints in different scenarios.
Code line breakpoint, when the code runs to the current line, the performance of the code will pause
2.2.1 Click on the line number of the source code in the Sources panel
When a blue icon appears in the row corresponding to the row number column, it indicates a successful break point. In the breakpoints on the right, you will receive information indicating that you have a breakpoint, displaying the corresponding line number. You can also uncheck, edit, or delete breakpoints
We can see six operation buttons controlling breakpoints in the upper right corner, corresponding to different operations
During the development process, the use case list can still be loaded at the beginning, but suddenly there is no data returned. Upon checking the interface, it was discovered that there is an issue with the moduleIds parameter
So breakpoints were set on the relevant lines of code, and when the performance reached line 149, the value of moduleIds was [46115417]
But when executed to line 152, the value of moduleIds is [undefined]
It turns out that there is a logical conflict between these two places, and the later logic covers the earlier logic
The problem was quickly identified and resolved. If using console.log, it may be necessary to write several consoles in the code, save them, refresh the browser to print, and after troubleshooting, it may be necessary to delete them. Therefore, when encountering some problems, the efficiency of troubleshooting can be greatly improved
Sometimes, we don't need to pause our code like a line break. We just need to print the relevant information on the console without interrupting our code performance. At this point, LogPoint comes in handy. Its syntax is similar to that of console.log, allowing us to quickly write our debugging information without interfering with our code like console.log, and without having to worry about deleting it later
When our code has errors that trigger corresponding exception errors, we sometimes find it difficult to quickly locate where the problem is. We can use exception breakpoints to immediately break when an exception occurs, so as to quickly find the code that is causing the problem, and view relevant variables and call stacks to help us troubleshoot the problem.
There are two types of exception breakpoints, which can be set at uncaught and caught exceptions respectively
2.3.1 Pause uncaught exceptions
For example, in the following code, aa needs to access a non-existent variable, which is problematic. This is also a problem we often encounter in our code
We can check Pause on unaught exceptions in breakpoints, which will naturally pause when the code executes these abnormal codes
2.3.2 Pause on caught exceptions
The following code has already caught an exception. In this case, you can check 'Pause on cause exceptions' to pause and handle the line of code that caught the exception
When there are issues with user interaction, we can add event listeners and breakpoints to capture these events and check for problems during interaction. You can check the corresponding event in the Event Listener breakpoints on the right side of the Source panel
The frequency of use is not high, and it is useful to study how to operate DOM in specific scenarios
When we are viewing and debugging a complex piece of code, it can sometimes be difficult to quickly clarify its call relationships from the code file. At this point, we can use the call stack to help us quickly clarify the logic and troubleshoot issues
Stack is a data structure whose internal elements satisfy the characteristics of last in, first out. We can perform stack in and out operations on it
In addition to viewing the call stack through breakpoints, sometimes we also use console. trace() to output the current function call relationship. For example, by adding console. trace() to the corresponding position in the following code, we can see the call stack information at its current position
In the browser, if you need to frequently use some common logic during debugging, you can save its code snippets in Snippets. When you need to run it on any page, you can directly run it
If some abnormal data causes problems on the page, we can directly use that abnormal data to debug locally. Of course, if the backend interface is not yet good, we know that the structure can also mock the data
5.2 Replace Response Header
If there are some scenarios that require adding or modifying response headers, custom modifications can also be made
6.1 Copy, paste, and drag elements
When the product needs to make some positional adjustments to the already developed pages, we may need to make a significant change to the code in order to show her the effect, but later we have to change the code back. At this point, we can utilize the capabilities provided by Chrome, such as copying, pasting, and dragging elements, to quickly adjust the page layout and show the product the effect without changing the code
When we need to quickly debug the code of a file, we can simply press Command+P shortcut keys to start the search floating layer, enter the file name or file path name, and quickly find the corresponding file. After selecting and clicking, we will go to the sources panel to open the corresponding file
When we have a corresponding code keyword and want to open its corresponding file. Chrome has added a global search code feature, which allows us to open the corresponding search panel
When we see some excellent websites and want to quickly view and learn from their style information, we can use CSS Overview to quickly obtain relevant information, which is very useful and interesting
This article introduces breakpoint debugging, sources panel, and some debugging techniques used in daily life, which help us provide new perspectives and ways to solve problems in future development and double our development efficiency