Why use an online environment for code debugging?

In daily development, when the interface document comes out, the front and back ends can be independently developed. The front end can use some online mock tools to simulate the interface, adjust the page, and reduce the time of joint adjustment.

However, in some cases, it is necessary to use the online environment for debugging:

  1. The data in the back interface is cross-domain restricted, or the interface requires an online login identity (cookie, etc.)
  2. Or a page that has been deployed onlinebugOffline development without specific environment debugging and so on.
  3. Other scenarios are easier to debug using an online environment

When we run into these problems, the simple idea is to estimate development locally, then deploy to an online environment to see the results, then debug again, then deploy to an online environment to see the results…… This is extremely tedious and inconvenient. At this point, let’s consider, can we use an online environment for code debugging?

So how do we do that?

Specific idea is, when we log in the online environment, online environment will return already deployed code, in this process, we can use caught tool, the request online already deployed code requests to intercept, replace with local code files back to the browser, as long as the replacement file one-to-one correspondence, online environment still can normal run, Since this process is transparent to the browser, we can deploy native code to the online environment and debug it as we go along

The specific operation is:

  1. Log in to the online environment
  2. Use a tool to capture the packet from the middle, intercept the code request to be debugged, and return the local file.

Of course, there are many kinds of tools. Here’s Fiddler as an example

The specific implementation

1. Locate the file where the online code to be debugged resides

For example, if I want to debug a sureSign () method, I start by locating the file that the method is in on the console

2. Find the request corresponding to the file resource

I still look it up on the console

In 3.FiddlerInside intercepts the request and returns the local file instead

This already allows local files, instead of remote files, to be tuned locally using the remote environment

But if the file is associated with another file after the framework (such as Vue + Webpack) is packaged, if replacing one doesn’t work, we can replace the whole file

Let’s replace the index.html first

Then replace the JS resource

That’s it

Of course, the use of packet capture can also achieve a lot of things, this is just a development debugging with small skills ~