location.assign('http://www.bing.com');If it is a page jump code that must be executed after the login or certain logic is successful, does it need to be encapsulated into a global method? Is just one sentence really necessary?
In other words, making full use of the editor's global replacement and other functions can also improve performance, although it is minimal~
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
If there is no logical judgment, just put a jump address in a constant. If there is a business logical judgment, encapsulate it.
If it is pure jump logic, then there is no need to encapsulate it into a separate method. You can put the connection in a constant file. Because what you said here is just one sentence of logic, there will be no logical changes here, but what may change is the connection address. For unified management, then put it in a separate constant file.
If this link-hopping process has its own logical judgment, such as what conditions to jump to which address. Then it can be encapsulated into a method for calling elsewhere. In this way, only one place needs to be modified when this piece of logic changes.
So whether to encapsulate and what to encapsulate depends on the changing needs
I wrote everything directly in the last project and felt there was no need to encapsulate it. And I'm not sure whether it can improve performance. I haven't compared it myself.
Encapsulating code is to reduce the duplication of code. For a line of code, it is almost the same whether it is encapsulated or not. Because if you encapsulate it, you have to write another piece of code to reference it, and the amount of code does not change much.
Premise: There is such a piece of code that is used in many places, and there are not many personalized changes in each place
If it were me, I would put it in one place, and then call it uniformly from one place (it can be global, or it can be util, etc.) for the purpose of:
Reduce the difficulty of possible expansions in the future. If you find that you need to add more things later, it will be easy to make changes
Reduce the workload during modification. If you want to change the href, you don’t need to find and replace them one by one, reducing the possibility of errors
Easy for debugging. You can know exactly where to jump from, instead of jumping to many places. If it jumps inexplicably, the interruption point will be directly hit at this place, and then you can find the problem by looking up. Instead of needing to hit many breakpoints in different places.
With this simple logic, it is obvious that the convenience and simplicity of the code are far greater than the performance of the code, so I will not consider performance issues