Author: Jiang Jiting, chief front-end architect of Individual Push Web front-end
Right now the front end is hot, the technology is coming out all the time, and the front end people are learning all the time. So are there any “lazy” ways to accomplish coded KPIs more effectively? I have been engaged in front-end development work for many years, responsible for front-end architecture design and implementation practice of many large projects of the company. This article will talk with you about the “way of project practice” and “way of change” of front-end.
Before we get down to business, let’s review the history of the front end. The front end, in its earliest stages, is also known as a “graph cutter” — writing simple static pages that are then assembled by the back end. Later, with the development of business, more complex business requirements are generated. JQuery, Bootstrap and other products come out one after another to help us develop faster. With the strengthening of external requirements for front-end business, pages become more and more complex, and the development of the original mode becomes more and more difficult. The concept of MVVM, angular, React, and Vue frameworks were born, ushering in a new era of front-end development. So, how to find the front “Tao” in the wave of development?
First, a quick story:
The traveler asked the old monk, “What did you do before you attained enlightenment?” The old monk said, “Chop wood and carry water for cooking.” The traveler asked, “What about the enlightenment?” The old monk said, “Chop wood and carry water for cooking.” The traveler asked, “What is enlightenment then?” The old monk replied, “Before the Enlightenment, when you chop wood, remember to carry water; when you carry water, remember to cook; After enlightenment, firewood is firewood, water is water, cooking is cooking.”
It is not hard to see that the old monk’s “Tao” refers to focusing on one thing at a time. The same goes for the front end. Before we knew it, we thought the front end was complicated because we were thinking of several features at once and writing everything out in a flash, but the quality of the code was not high.
What is the way of front-end engineering?
The most important work is to effectively break down the code hierarchy, which we can simply divide into four parts of the project: framework, components, services, and business pages. The framework is divided into basic framework and business framework. The purpose of building business framework is to provide an overall solution to make other blocks (layers) more pure. Make good use of the component library (basic components (including styles), business components) to reduce the duplication of wheels; A service is a uniform set of methods or a uniform treatment of a model layer; The point of a business page is to focus on the business itself. In addition, there are modularity, microservices and so on. We assume that there is trust between layers, and when we are doing one of them, we can pretend that the other parts don’t exist and just go with what we need.
Alternatively, we can divide the layers into the data layer (which encapsulates some basic processing of the data), the logical layer (which may be split into multiple layers when the project is large), and the view layer.
Partitioning the directory structure is critical in dismantling a project. Of course, the CLI now takes apart some of the directory structure for us, such as the following vue-CLI generated structure for us:
It automatically helps us create a directory structure when we create the project, making it easier to initialize the project. However, this project structure is too simple and closer to demo state, so we need to improve this structure. We need to build a business framework, plan for a more robust directory structure, package a layer of method libraries (permissions, requests) and provide unified processing functions and global interception related processing, with the necessary family bucket packages, etc.
Two, front-end engineering directory structure split practice
Below is the structure of one of our projects. It is relatively complex, including both PC and mobile parts, and the common part is in the common file. It includes assets (images, resource information), Components (some common components), filters, mixins (some modules for merging), Services (common services), stores (data stores), utils (preprocessors, tools).
The PC folder has some unique static resources, files, plug-ins. The same goes for the Mobile folder. Components in this project tend to be generic business components, while plugins tend to include plugins that cause changes in performance. Router is some routing information. Views are components of some businesses. Through this layer, students who write business can write in views; Even if one person is in charge of all the parts, he can stay focused on all parts.
Iii. Examples: The architectural design practice of some products
Getui has a relatively rich product line, some of which have similar main functional modules of different products, but these products are independent of each other. So, if we develop individual products one by one, the code will be copied many times, and if one needs to be changed, the others will need to be adjusted accordingly. So how do we solve this problem?
Here are a few specific concepts.
Product: Each specific APP is a product.
Project code: includes generalized gulp/ SRC /cloud, and narrow SRC folder.
Based on this, we came up with an approach: source code as a separate piece, with different configurations and special components for different products, and then packaged into different products.
This is a schematic drawing based on the above design pattern.
We have an internal component library, including base and style components.
Personalized part
First, these modules are divided into small components, which are represented by triangles, circles and squares. Then combined with the original basic components, component functional components; Then, through the accumulation of functional components, each specific business function is formed. As a whole, therefore, the personalization part (the continuous self-invocation of business functions) is a module that can be assembled into a product, whose final form is determined by the associated configuration. In addition, the block of the slot in the View is the product that defines the final representation of the business components in the slot.
Public part
The data layer provides some support services, mainly account services, related to temporary storage. We also divide the data layer: API Call draws on RPC thinking to form a universal request sending method; A Model Call is an early pattern that separates specific request services; Get JSON is for a part of the file that is not encapsulated as the source data of the back-end interface.
The view layer has two main parts. Different products have different color schemes and different copywriting.
The above is a structure of our whole.
Some TIPS on architecture module division
Here’s a look at some of the tools we need: 1. Write a node applet to check some permissions, more accurate than the naked eye; 2. Self-built CLI, integrated some solidified work tools into its own CLI based on the project practice process. As the project evolved, we separated the apps folder into a separate repository and wrote a script that was soft linked to the main program so it could run directly.
Earlier, we also mentioned component libraries. In addition to the business framework segmentation, we also need to classify components, including: style library, public function library, js plug-ins, business components, modularity.
As for the scope of component library, we can divide it into full scope level component library, product line level component library, project own component library and special component library.
Five, the way of front-end change
Because the front end is so hot right now, everything is changing: the stack, the business, the design, the architecture, and so on. Not only that, but business requirements, developers, project complexity, implementation thinking, and so on are changing, and it’s possible that our code is slowly “going bad” as a result of these changes.
We find that the bigger the code, the faster it breaks because there are too many points to touch. Therefore, when code has “bad smells”, we need to check them out as soon as possible. There is an effect called the “broken window effect” — where there are many Windows in one place and one pane is broken, and if you leave it alone, you’ll find more and more broken later. So there’s a problem with the code that needs to be fixed immediately, otherwise after years of building up problems, we end up abandoning ship and starting from scratch.
The strength of the last practice can become the weakness of the next. Early on, we found that several lists in the secondary menu had similar business functions, and we combined them together for common ground and differences, making it easy to manage. Later, there were more and more second-level menus with similar functions, and all the second-level modules were mixed together, and the differences added up, and it was very painful when we tried to change them. One solution is to do some refactoring and fixing when we find that code practices are “awkward.” But it doesn’t happen overnight. It doesn’t happen to a certain point. It’s going to happen all the time.
Another change we have to mention is some projects in the official website, that is, from SSR to SSR. When the front and back ends are not separated, server-side static page rendering such as ASP, PHP, JSP is required. Later, more and more powerful front-end engineering capabilities, can achieve browser side rendering; Until now, the SSR of VUE was born. Now we may use the way of SPA development, the disadvantage of which is that SPA may be “heavy” for the official website, or we are more accustomed to the current development mode, which is difficult to adapt to the development of jQuery era. On the other hand, there are benefits to having multiple pages — each page is very independent, allows for better SEO, and users can enjoy faster arrival times. So, from SSR to SSR, it looks like a step backwards, but it’s actually a spiral.
There are also changes taking place outside. Angular 6, Webpack 4, Node’s new product…
Six: conclusion
The market is changing so fast that while technology is important, ideas are more important than technology. Technology can never be learned, but ideas can be compared and even innovated. Based on new ideas, maybe you can also write new algorithms, new techniques.