In daily front-end development business code, we often need to debug data, so we often need to change the initialization data of some parameters or the data in the process.
Many times, however, you forget to go back after debugging the data you changed. It's good for a debugging scenario to depend on the modification of one parameter, but it's easy to miss it if you need to depend on the modification of several parameters.
Take two examples:
1. We have a button to trigger the pop-up window to open, and the control pop-up window is hidden as the variable showDialog, the initialization value is false, but the product says there is something wrong with the style inside the pop-up window, so we set the value of showDialog to true and then modify the content (because it is not possible to click the button every time to open the pop-up window effect)And finally set the showDialog back to false.
//Pseudocode var showDialog = false; //Control window is implicit, debugging depends on its variable value btn.onclick = () => { showDialog = true; }
2. We have a lottery activity. The logic is to compare the contents of prize_id after requesting the interface and getting the prize_id. Then we decide to show it in the view. But we need to debug the contents of a lottery result. Of course, we won't ask the interface to change the prize_id it returns, so we may change to the displayThe value of the module.
//Pseudocode fetch().then(prize_id => { showResult(prize_id) //Display lottery results, debugging depends on passing in values }) function showResult(prize_id){ //Code showing lottery results }
The problem is that most of the time we forget to go back, pop-ups open directly and win a prize in every lottery. This low-level mistake shouldn't be made, but I've also seen some app s that actually test code like this directly into production.
So in these business codes, I'm sure nobody will do pre-build validation scripts or unit tests, so we need a simple function to control variable assignment to avoid this low-level error.
I wrote a simple package specifically: https://github.com/ershing/de...
Usage:
//Introducing package dev-debugger import DevDebugger from 'dev-debugger' //Initialize dgb instances to control test values for variables let dbg = new DevDebugger({ debug: true }) //Bind to get a replacement method, or call dbg.debugVal directly let _r = dbg.debugVal.bind(dbg)
Instances have two methods: debugVal and debugCaseTag
/* debugVal(pro, dev) @params The first parameter passed in is the production value and the second is the debug value */ //You can also bind to facilitate subsequent calls let _r = dbg.debugVal.bind(dbg) /* debugCaseTag(pro, tag) @params The first parameter passed in is the production value, and the second parameter is the named unique label name */ //Prerequisite parameters with initialization let dbg = new DevDebugger({ debug: true, caseName: 'testPrize1', //Debugging use cases cases: { //Use Case Parameter Set 'testPrize1': { 'myPrize': 3 //Debug value for label name }, 'testPrize2': { 'myPrize': 6 //Debug value for label name } } }) //You can also bind to facilitate subsequent calls let _rt = dbg.debugCaseTag.bind(dbg)
So the example above can be written as follows:
1. Control the variable value of showDialog
//Pseudocode var showDialog = _r(false, true); //debug value is true btn.onclick = () => { showDialog = true; }
2. Controlling the value of the incoming explicit-implicit function
//Pseudocode fetch().then(prize_id => { showResult(_r(prize_id, 3)) //debug time 3 }) function showResult(prize_id){ //Code showing lottery results }
Of course, the debugCaseTag method can also be used above to place debugged values in the initialized functions.
However, when we build code, of course, we don't want any debugged code and debugged values, so I wrote another babel plugin: https://github.com/ershing/ba...
Usage:
//Modify the babel.config.js file module.exports = { "plugins": process.env.NODE_ENV === "production" ? ["babel-plugin-dev-debugger"] : [] }
Be careful:
With this babel plug-in, you need to import the package dev-debugger in your files (which is also good for separate debugging of single-file components), and don't assign instance methods. Instead, you can use dbg.debugVal or dbg.debugCaseTag directly, or _t or _rt after bind, but don't assign them to other variables.