Table of contents
Chapter 2 Methods to Solve Bugs
2.5 Whether the request body carries parameters
2.6 Annotate page rendering code
Remarks: This article is just a few methods that I commonly use in my work/study. If there is something that does not suit your "appetite", don't spray it. You can provide new methods in the comment area and learn together! ! !
Chapter 1 Preface
Reason: Bugs exist for our front-end many times. Why do we say that, because the things we use in the front-end are messy, and some bugs only appear under certain circumstances, so we need not Timed solution; we will use various components, different methods, native js, data types, timing of obtaining data, logical structure, rendering layer, etc. will be where our final problems will appear. Then how do we locate the problem? Next, let’s take a look at some of my solutions. If you are also a novice, you may also gain something! !
Chapter 2 Methods to Solve Bugs
2.1 Baidu
Don't laugh, Baidu is also a tool for us programmers. We can search on Baidu for the reported errors. There must be someone who has experienced a similar situation, then we can roughly locate where the problem occurred.
2.2 Youdao Translation
Why use Youdao translation? Sometimes the results on Baidu may not be useful to us, so we must know the general meaning of the error before checking the bug, so that we can locate it conveniently
2.3 debugger
Write a debugger after the code we want to break , and then we debug the code in the browser , debug it step by step, and then look at the logic of the code to ask questions (I personally don’t recommend this method for novices, you need patience , we will be at a loss when we enter some low-level code during the debugging process, but it is also a way)
- Write debugger after the code you want to break
- Run on the browser, pay attention to refresh the browser
Pay attention to the order of code execution:
2.4 console.log log printing
This method is a very convenient and friendly way to solve bugs, whether it is for novices or those who have worked for several years. By printing the results, we can locate the point and block of our code logic where the problem occurs. Cultivate the habit of printing console.log logs. Although it will be troublesome for us to delete during the software release process, it is really easy to use.
example:
2.5 Whether the request body carries parameters
The previous methods are basically aimed at our front-end itself. This method is aimed at when we connect with the back-end. When we pass parameters, we must carry the request header, request body, and Content-Type to see if they are all carried. It is complete and correct. When we carry all these parameters and report an error, we will see if it is a back-end problem.
- First understand the modules used
- Master the response headers (these few items in the understanding box are enough)
- Master the request header (these few items in the understanding box are enough)
- Master how to see the load (that is, the parameters carried by the request)
- Both the preview and the response are the data returned to us by the backend (just look at one of them)
When using the response data, it is very practical to give you a link to see the data structure returned by the backend
- Several request data error status codes that must be known
200: This is one of the most common status codes, indicating successful access
301: Permanent redirection (the requested resource has been permanently moved to a new location, relocating the path)
302: Temporary redirection
401: Unauthorized
403: Indicates access Rejected. Some pages require the user to have certain permissions to access (only after logging in)
404: Resource not found
405: The method is not supported, the server list does not contain the request method
500: Internal server error, usually a server error
----- See my other article for details
AJAX and its related knowledge application (very detailed)_ajax middleware_❆VE❆'s Blog-CSDN Blog
2.6 Annotate page rendering code
Overall, this method is cumbersome, which means that when the reported error is not particularly obvious or an internal component error, we can’t find the corresponding component with the naked eye. At this time, we put all the page-related code (html) If you comment out all of them, you will definitely not report an error, and then we will expand each page block step by step, from the parent element to the child element display, sibling elements will not be affected, step by step, when displaying a certain element, If the console reports an error, then my bug is likely to be in the method used by this element or the method used by the parent element. Let’s analyze layer by layer to see which method caused the error, and then solve it.
Examples I've come across:
See this article: [Vue warn]: You may have an infinite update loop in a component render function_❆VE❆'s Blog-CSDN Blog
2.7 Others
There are also some error reporting, character verification, format verification, judgment, component error reporting, whether data is not obtained, configuration problems of the native js method... These need us to accumulate slowly.
Chapter 3 Epilogue
Solving bugs is not something we can locate with just one or two clicks. What we need is our patience to gradually discover the problem and solve it. We are not good at everything, we are making progress in learning, come on! !
If any reader has any ideas to provide, welcome to leave a message in the comment area! !
Finally, I would like to give our programmers a word: the most admirable scene is actually the footprint of our own struggle; the most worth showing off is the achievements we have achieved through struggle! ! Come on, boy! !