A few years ago, the company needed to log in and register, and the estimated construction period was one month. As a result, the project became uncontrollable during the process, and it took almost three months to complete. In order not to waste the overtime work during this period, I reviewed the process of completing the project.
About Requirements Review
Let’s briefly review the requirements first. Registration/login has three channels: account/password, mobile phone number, and three-party (including WeChat QR code scanning, QQ authorization, and Weibo authorization). Through a series of rules and guidance, you will eventually reach the login/registration success page and then jump to the source web page.
The tasks to be completed include PC, mobile and WeChat.
The difference between the mobile version and the WeChat version is very small, the only difference is whether you can log in by scanning the WeChat QR code.
The requirements seem simple and clear, and it seems that a lot of logic can be reused, so the PC side is estimated to be half a month, the mobile side is estimated to be a week, and the rest is used for IE adaptation and problem solving.
About technology selection
Because it involves WeChat scan code login, the backend proposes that the interface use a polling method. I keep polling the status interface to obtain the status. For example, the WeChat login process requires WeChat scan code > obtain mobile phone number > guide to follow the official account > create/bind website account process, which roughly corresponds to the 4 fields given to me by the backend, and I determine which route to enter based on the presence or absence of the field.
What problems were encountered and their solutions
Old code
The old code was a mountain of shit. Pages were a patchwork of HTML, inlined CSS/JS, and PHP statements, with a single page running to four or five thousand lines of code. It was even coupled with other projects’ CSS (referencing their shared CSS). PHP includes were nested layer upon layer, and even JS logic lay deep within. (The only bit of old code I kept was the third-party login code, which later introduced a hard-to-debug bug.)
The solution was to refactor the front-end. Initially, we wanted to integrate the logic for multiple pages into a single PHP file, monitoring the browser’s hash value to change routes. Later, we realized that each route had its own initialization logic, so we added a simple lifecycle. Later, we realized we needed to reuse components, so we adopted the Vue framework and imported them using the script tag.
Code Reuse
Due to some reasons of the old project path, import cannot be used, so include has to be used instead.
All variables that need to be reused should be made global, and symbols or singletons should be used to prevent variable pollution.
The Vue template is written in an HTML file, and the logic part uses the script tag include of x-template to introduce the Vue template code.
Stylesheet
Use node-sass to monitor changes in scss files, compile scss, and generate corresponding css
compatibility
The project needs to be compatible with IE10, so babel-browser and pollyfill are essential. Real-time compilation will affect performance to some extent, and I haven’t found a solution yet.
Then the style needs to be compatible with post-css, and the prefixer plug-in of vscode is used directly.
Polling
Each page needs to poll the interface. If each route maintains its own timer, there will be a lot of duplicate code and the risk of memory leaks.
Therefore, a polling singleton class is added to maintain the polling logic. The routing guard is used to start the timer when created and pass in some required parameters and callbacks, and then destroy it after destory.
The advantage of this is that it prevents the simultaneous existence of multiple timers due to forgetting to manually destroy them, and facilitates unified processing of the return value of the interface.
Reflection and Optimization
In general, the pitfall of the front-end was the forced use of es6 + vue + sass without using any packaging tools. This solved some problems, but also introduced many problems.
Code maintenance: Compared to the previous css style sheet, sass is indeed much clearer, but it also brings problems. Because there is no declaration file, other people who take over my code do not know that they need to use node-sass to compile it.
User Experience: Vue-router’s route redirection is a partial refresh, providing a better experience than traditional tag-based redirection. However, due to the several-second polling interval, some endpoints may be slow to respond. Most users definitely don’t want to experience lag when registering.
About Performance: Babel compilation in a production environment can affect performance, but you can use Babel-compiled code in a production environment after the version is stable. Polling can also consume server resources if users remain idle. You can use WebSocket and regular Ajax instead of polling.