1. Before the words

I certainly believe that the big guys can go from typing the first line of code to deployment with no test run to verify that a shuttle is complete and without any bugs very 🐂🍺.

But I can’t, so I need to utilize some front-end Debug skills to allow me to continue moving bricks 🌚.

Just kidding. To err is human. The proportion of Debug time in our daily development is usually quite large, and if the DDL is approaching and the head is not hard enough, cutting out Debug time seems to be a cheaper way to reduce risk.

Here’s a quick tutorial on useful front-end debugging skills.

2. Debug logs

The first Debug skill you learn is logging on the console. Logging on the console is the simplest Debug skill. Generally, you only use the following interfaces:

console.log('log'); // A generic way for the console to print logs
console.info('info'); // Displays information level logs
console.debug('debug'); // Prints debug logs
console.warn('warn'); // Displays warning level logs
console.error('error'); // Prints error level logs
Copy the code

The use effect is as follows:

For more advanced uses of console, see juejin.cn/post/706585…

To master the basic requirements of Log debugging, you must not only learn the console log interface, but also understand the log specification of the action of log debugging.

We could log anywhere in real development, but ineffectually logging would contaminate the console log, making it harder to extract key information and making “log debugging” inefficient.

Instead, “logging effectively” and “making it easier to extract key information” will make logging more efficient, which is the core of logging specification.

“Effective log” mainly find “log”, this technique is “directly in the PM log” forward step by step, such as card title display an error, then rendering code in the card printing card data, and then go to find card printing card data at the data changes, have been found card data acquisition card printing data.

“Reduce the difficulty of extracting key information” means to make the output log “obvious”. The method varies from person to person, and there are no restrictions on the following points:

  • Add prefix to implement log classification, for exampleConsole. log('__ delete XXX__', 'ID = '+ ID')
  • Function after debugging delete log, availablehusky+lint-stagedDisable the submitconsolecode

Here I believe that readers also have a basic grasp of “log debugging”.

3. Breakpoint debugging

If mastering “log debugging” is a beginner’s front-end scholar, mastering “breakpoint debugging” is a qualified front-end scholar.

Log debugging is simple and crude. It is extremely challenging for front-end scholars to standardize the action of logging, and logging is also a time consuming activity (repeatedly writing log code).

Most of the purpose of “log debugging” is to observe the change of variable data in the process of code execution. By observing the execution process and variable data to find out the problem point, is there a better and more convenient alternative to “log debugging” debugging skills to achieve this purpose?

Of course there is, namely “breakpoint debugging”. Breakpoint debugging can “output” more detailed information than log debugging, making debugging more efficient.

To enable breakpoint debugging using code is very simple, just a keyword debugger, using the following example code:

function doSomething(who) {
  debugger;
  const word = 'hello ' + who;
  console.log(word);
}

doSomething('hello world! ');
Copy the code

Breakpoint debugging depends on debugging tools. There are many kinds of breakpoint debugging tools. The two common ones are DevTools and IDE.

3.1 DevTools

Most browsers come with this tool. The shortcut keys for opening the debugging tool are Command + Shift + I or CTRL + Shift + I.

The open “Source” TAB, where the code is debugged, looks like this:

If we visit a page using the sample code above with the debugger open, we can pause the code execution at the debugger keyword as follows:

In the figure above, we can clearly query the following information:

  • The left pane navigation shows the code file directory information
  • The middle panel shows the current code content and breakpoint location information
  • The right panel “Scope” displays the variable information of the current execution context and “Call Stack” displays the complete code Call Stack information
  • .

Tools are provided at the top of the right panel for skipping, stepping, entering context, and returning context for code execution, as shown below:

Used here is Chrome DevTools, about the use of more detailed methods can refer to the official documentation, links here 👉 developer.chrome.com/docs/devtoo…

3.2 the IDE

VSCode, a common code editor for front-end development, also has debugging tools built in.

If you click Run and Debug and select Chrome, VSCode will automatically launch Chrome to visit the launch.json configuration page and display the debugging information of the current page as follows:

We can see VSCode debugging tool functions presented with Chrome DevTools is consistent, the principle here is not much ha, interested readers can refer to this document 👉 zhaomenghuan.js.org/blog/chrome…

4. Online debugging

Front-end Debug can either log information about the code execution process on the console or observe information about the code execution process on the Debug tool card breakpoint.

For local applications, the two Debug methods can be used directly. What about online applications?

To think about how to Debug online applications, firstly analyze the characteristics of online applications: online data + online code.

The front end cuts primarily from the code side. Online code is usually built and distributed as a package of native code, so how we Debug depends on whether we have native code for the version of online code.

4.1 there is native code for the online version

If you have native code, you can start dev locally and hit log or card breakpoints, just worry about getting online data.

The modern front-end is basically the development mode of separation before and after, so the way of acquiring online data is basically realized by proxy. Due to the same origin policy at the front end, there are two types of proxies:

  • Local Domain Name Agent (Localhost)
  • Online domain name proxy

4.1.1 Local Domain Name Proxy

Front-end development The common development packaging tool Webpack can be configured using proxy. The configuration example is as follows:

module.exports = {
  / /...
  devServer: {
    proxy: {
      '/api': 'http://localhost:3000',}}};Copy the code

More details please refer to the official documentation ha 👉 webpack.js.org/configurati…

4.1.2 Online Domain name Proxy

Compared with local domain name proxy, online domain name proxy is more flexible. Local domain name proxy is the data interface that needs proxy need to be set manually, but domain name proxy we only need to set the front-end resources that need proxy.

After local webpack start dev, for example, http://127.0.0.1:3000/index.html provides local access to address, and rely on the front end of resources request path to http://127.0.0.1:3000/js/.

After we set the domain name agent debugger.com/index.html to local address http://127.0.0.1:3000/index.html, will return the local HTML, the front end of the corresponding will request path as debugger.com/js/ resources.

Then we’ll to domain name agent debugger.com/js/ to http://127.0.0.1:3000/js/.

There are many online domain name proxy tools, including Charles and Whistle. Here I use Whistle to demonstrate:

  1. First, according to the command NPM install -g whistle to complete the installation, run w2 start to start the agent tool

  2. Visit the http://127.0.0.1:8899/ proxy configuration page to configure the proxy

  1. Enable setting system network agent, as shown below:

  1. Access the page address debugger.demo/index.html

More details on Whistle can be found in the documentation 👉 wproxy.org/whistle/

4.2 No local code for online version

The absence of native code for the online version is a special case because the developer role typically has code permissions. However, if you are in a troubleshooting role such as testing, there will be no local code for the online version.

To change the code online, use the Override function in Chrome’s “Source” panel. The following is the actual operation:

  1. Enable the “Override” function, as shown below:

  1. Find the request for the corresponding code in “Network” and select “Save for Overrides”

  1. Refresh the browser and return to the Override panel to find the requested resource saved in the previous step and save the modification

  1. Refresh the browser again and you can see that the console outputs a log

5. The last

This article gives a brief overview of the Debug skills that can be used in scenarios THAT I know of, but it is not very comprehensive. If there are any mistakes, please point them out or add any other Debug skills that I don’t know of in the comments section.