Many students do not know why debugger to debug, console.log can not?
Also, how can I debug complex source code when I can use debugger but still can’t understand a lot of code?
This article will talk about why you should use these debugging tools:
console.log vs Debugger
I’m sure most of you use console.log to debug, printing the value of the variable you want to see on the console.
This meets the requirements, but not when it comes to printing of objects.
For example, I wanted to see the value of the compilation object in the webpack source code, and I printed it:
But you’ll notice that the value of the object is not expanded when it’s also an object, but instead prints a string like [Object] [Array].
What’s more, if the printout is too long, the buffer size will be exceeded, and the terminal will be incomplete:
Whereas if you run it with debugger and make a breakpoint here to see it you don’t have these problems:
Some students may say that it’s still convenient to use console.log to print a simple value.
Like this:
Really?
Might as well use logpoint then:
The code executes to this point and prints:
And without polluting the code, wouldn’t the console be deleted after debugging with console.log?
But logpoint doesn’t. It’s a breakpoint setup, not in the code.
Of course, the most important thing is that Debugger debugging is able to see the call stack and scope!
First is the call stack, which is the execution route of the code.
For example, if you look at the function component of this App, you can see that rendering this function component goes through the workLoop, beginWork, renderWithHooks processes:
You can click on each frame of the call stack to see what logic is being executed and what data is being used. For example, you can see the fiber node of this function component:
Then there’s scope, and clicking on each stack frame shows you the variables in each function’s scope:
With Debugger, you can see the execution path of the code and the scope information of each step. And you use console.log?
You can only see that variable value.
The difference in the amount of information you get is not a little bit, debugging for a long time, other people will be more and more clear about the flow of the code, while you use console.log? Still the same, because you can not see the code execution path.
So, whether you’re debugging library source code or business code, whether you’re debugging Node.js or web pages, it’s recommended that you use the Debugger to hit breakpoints, stop using console.log, and even if you want to print out logs, you can use LogPoint.
And when troubleshooting, if you use Debugger, you can add an exception breakpoint, and the code will break when it reaches the place where the exception is thrown:
You can see the call stack to sort out what code went before the error, and you can see the value of each variable by its scope.
Wouldn’t it be easy to troubleshoot errors with these things!
And you use console.log?
Nothing. You’ll just have to guess.
Performance
As I said earlier, Debugger debugging allows you to see the execution path of a piece of code, but the execution path of a piece of code is often quite convoluted.
For example, that React processes each fiber node, calling beginWork for each node, and then processes the next node, calling beginWork again:
It’s like if you take a path, then go back to the main path and take another path, with Debugger you can only see the execution path of the current path, not the path of the other paths:
This is where you can combine the Performance tool to see the full picture of code execution, and then use the Debugger to drill down into the details of each code execution path.
SourceMap
sourcemap is important because what we have executed is compiled and packaged code, which is basically unreadable, and it doesn’t make much sense to debug this kind of code, while sourcemap allows us to debug the original source code directly.
For example, with vue, we can debug ts source code directly by associating it with a sourcemap:
nest.js as well:
If you don’t use sourcemap, you want to understand the source code, but you are debugging compiled code, how can you read it?
Read a line
Debugger, Performance, SourceMap said earlier is just a tool for debugging code, that will be debugging tools, still can not read the code how to do?
I don’t think that’s possible.
Why?
Take the react source code:
The switch case is readable, isn’t it? You can read the trinomial operator. Function calls.
Every line of code can be read, and isn’t that what the whole code consists of?
Plus we can single-step the execution to know the code execution path.
Why is it that each line of code can be read and understood, but not when it is linked together?
That should just be too much code and you’re not spending enough time on it.
First to read a line, a function, read a small function of the realization of the process, slowly accumulate, and then understand more and more after, you can read the code will be more.
This article talks about why you should use debugging tools and how to read complex code.
console.log has too many drawbacks, large objects can not be printed, will exceed the terminal buffer, object properties can not be expanded, etc., do not recommend that you use. Even if you want to print, you can use LogPoint.
With Debugger, you can see the call stack, that is, the execution path of the code, the scope of each stack frame, and you can know what the code has gone through from the beginning of the run to the present, whereas console.log can only know the value of a certain variable.
In addition, when reporting errors, you can also use exception breakpoints to comb through the code execution path to troubleshoot the cause of the error.
However, Debugger can only see one path of execution. You can use Performance to record the entire flow of code execution, and then combine it with Debugger to drill down into the execution details of one of the paths.
In addition, it only makes sense to debug the initial source code, otherwise debugging the compiled code will be much less informative. You can use SourceMap to associate to the source code, no matter it is the source code of Vue, React or Nest.js, Babel and so on.
Will be able to debug after debugging, you can debug all kinds of code, there is no source code that can not understand, because each line of code is the basic syntax, are able to understand, if you can not understand, only may be too much code, you need more patience to read a line of code, a function, make sense of a function implementation, slowly accumulate on the good.
After mastering the debugging code based on Debugger, Performance, SourceMap, etc., all kinds of web pages and Node.js code can be debugged, and all kinds of source code can be read!
