编程知识 cdmana.com

Debugging and testing network request load of front end tips

demand : Change one of the front end ajax Load of network requests (payload) And test to ensure normal function

If this revision is big , Or the original build payload It's a complicated logic , We may need to modify and test over and over again .

If this ajax request If the impact on the back-end resources after sending is very small —— such as Create a book record , Update the tag of an article , In fact, we don't need to think too much , direct Modify and test at the same time That's all right. .

Because these painless resources are created or modified during testing , You can easily delete it after the test , It won't make a big difference .


however , If the ajax request In the back end, it will Trigger heavy operations  —— For example, creating a service cluster , Redeploy a service node , We have to think carefully .

On the one hand, this kind of heavy operation will take a long time , On the other hand, it will actually modify or consume online resources , Random and frequent testing is not appropriate .

This situation requires us to Except for the last acceptance or two , The rest of the tests should not really send requests to the back end .

So how do you do that ?


Scheme 1 : Modify and comment on the requested code

If this is the original code

getFormData = ()=> {
  // construct the payload from form data
}

onSubmit = () => {
    const payload = getFormData();
    httpClient.postRequest(payload);    
};

Test time code

getFormData = ()=> {
  // construct the payload from form data - updated some code and logic
}

onSubmit = () => {
    const payload = getFormData();
    console.log(payload); 
    //httpClient.postRequest(payload);     
};

We put httpClient.postRequest(payload); Comment out this line of code , And increase console.log(payload); hold payload Call console Check it out . Confirm the modified payload When it's absolutely right ( This process can be repeated many times ), Remove the comment code .


This scheme does avoid the initiation of real network requests , The logic is simple and the code is clear .

But the disadvantages of this approach are also obvious , We Modified the original working code —— That is to say httpClient.postRequest(payload);  At the end of the development , If we forget to remove this line of comment , Push the code online , This will cause the form to fail .


Option two : Set breakpoints in the form submission code

Take the above code as an example

getFormData = ()=> {
  // construct the payload from form data
}

onSubmit = () => {
    const payload = getFormData();
    httpClient.postRequest(payload); // set breakpoint here
};

We need to be in httpClient.postRequest(payload); This line breaks in

How do you do that ?

open Chrome Developer tools , And then look at the picture below ( Pay attention to the arrows )

ebbf919f2ffe52701c2258f651ecca82.jpeg

Before triggering a network request , Code will be intercepted by breakpoints , Now we can see in the right column ajax request Of payload 了 .

Because breakpoints block code execution , This ajax request It will not be sent to the server .

If you find payload incorrect , After continuing to modify the code , It only needs Refresh the page You can reset the current page js Code running state ( Break away from the breakpoint ).

This solution solves the problem of solution one —— Do not modify any code that would otherwise work

But the flaws of this approach are also obvious : If the break point js The file is the code file that is being modified , Once you increase or decrease the number of lines of code , The location of the breakpoint is still on the original line ( Or the closest executable code ).

for instance : In the screenshot above 23 Line code is now  httpClient.postRequest(payload)  But the rest of the file adds or subtracts code , Lead to  httpClient.postRequest(payload)  Now in 27 That's ok , And the breakpoint shifts to 25 Go ahead ( because 23 Yes, it can't be enforced )

a2f9b6124f4350652095e5ae12312bca.jpeg

To avoid that , We can do it in  httpClient.postRequest(payload);  Before to add debugger —— Can have the same breakpoint effect ( The premise is to open Chrome Development toolbar ) And it doesn't shift at will , The code is as follows :

getFormData = ()=> {
  // construct the payload from form data
}

onSubmit = () => {
    const payload = getFormData();
    debugger;
    httpClient.postRequest(payload); 
}


But use debugger It will bring disadvantages similar to scheme one —— After the development is complete , Remember to clean up debugger This line of code .

Another solution to avoid breakpoint offset is to hit the breakpoint to the unmodified js On the file , But there are preconditions —— Aforementioned httpClient Code It's in the other js In the file .

All in all , Scheme 2 uses Chrome Developer tools break point perhaps Join in debbuger There are still limitations , In some cases it's not very convenient .


Option three : Skillfully use Chrome Developer tools take web pages offline

What's the fastest way to prevent requests from being sent to the back end —— Pull out the cable and break the net !

Of course , With chrome Developer tools help , We can take a web page offline without having to unplug it , The details are shown in the figure below ( Notice the arrow )

79a0c5c2cea306c61421ae077cacca68.jpeg

Click the third arrow to see request Of payload And other information

23403a95a10e8cf13e24566db4b08b3d.jpeg

Although the website is offline , however ajax request You can see all the information about .

This scenario does not affect other code as scenario one does , It won't be like plan two because js The impact of changes to the document .

Modern front end frameworks like React perhaps vue Can be hot deployed —— Modify the code , The interface will automatically refresh , But in fact, the underlying principle of hot deployment relies on network requests , therefore Offline web pages can cause hot deployment failures . therefore , Once the code has been modified , Remember to reopen the network to refresh the page , Go offline before testing .

This is the drawback of scheme three —— You have to turn the network on and off repeatedly , The operation is a little tedious .




Front end tips debug This is the end of this article , Each of the three schemes has its advantages and disadvantages , Which one do you like best ?


expand :

In fact, this article is just a piece of advice ,Chrome Developer tools are a good helper for all front-end developers in their daily development , I recommend that you find time to read the official documents carefully , Learn more about how to use it

https://developers.google.com/web/tools/chrome-devtoolsdevelopers.google.com



版权声明
本文为[osc_ 6lwba9kg]所创,转载请带上原文链接,感谢
https://cdmana.com/2020/12/20201224142424496i.html

Scroll to Top