Front-end development: Modular-efficient reconstruction and modular Reconstruction

Front-end development: Modular-efficient reconstruction and modular Reconstruction

Speaking of modularization, we may first think of Module Design in programming, Program Design in the unit of function blocks, and finally form the final product through the selection and combination of modules. Applying this kind of thinking to page building is nothing new. I believe that a lot of page building engineers have gone through these stages: the first stage is to write styles from top to bottom based on their habits in a css file, the primary purpose of the design presentation is not to consider whether there are public styles. The second stage is to extract general styles from different pages, such as public colors, icons, and buttons, some basic elements are reused. The third stage is to extract public function modules, such as navigation and copyright information, to reuse some public modules. Front-end framework sharing

The third-stage method just described already contains the modular idea, and many teams also have a mature modular development solution. For the first time, I heard about the modular construction method. When I was working in a Korean Internet company three years ago, some products required a function module or component called UIO, in order to achieve the highest degree of module independence and reusability, many colleagues in the team and I thought that this work method constrained the freedom of coding, too many structural constraints reduce the work efficiency, and there are also differences between products, and they are not applied to the entire team.

So what are the advantages if we use modular building? Maybe at the beginning, a process of adaptation may lead to team members who previously thought similar to me at the time. But when everyone adapts to and is familiar with this kind of work style, it will certainly greatly improve the efficiency of page building.

Suppose there is a scenario where the team receives an urgent project with a lot of pages and a lot of work. The first team did this: The team lead assigned several pages to each person and divided them to finish their respective pages, uniform delivery: For modules with similar structures on different pages, a careful team may agree to let someone write the code and copy it to everyone who needs it, then, let everyone write all the content on their respective pages, and the completed task is the most important. The second team divided the public or repeated modules based on all pages in advance, and then assigned them to everyone by module uniqueness. Someone was responsible for setting up the framework, creating modules, and finally merging the frameworks and modules, then, the page is delivered in sequence according to the development work plan. The comparison result is that since the second team is composed of multiple people to create a page, they can produce the first page required for development at the fastest speed, in addition, the more modules that can be reused on the page at a later stage, the whole working time may be halved from the first team. The reuse of modules not only has a great impact on the team's working time, but also downstream developers do not need to re-develop code for the same module. In addition, the amount of code redundancy and the code scalability of the two working methods during product upgrade also reflect a big gap. Furthermore, if your team is going to use BIGPIPE or LESS development methods, the modularization of CSS is the best means of cooperation, or necessary.

When we decide how to use modular construction, following certain principles will be of great help for the smooth advancement of modularization.

An article on object-oriented CSS once pointed out that,Object-oriented CSS has two main principles: separate the structure from the skin, separate the container from the content. The first principle is embodied in the modular idea. It can be understood that the design and production of modules are separated from the layout framework itself, which means that your modules cannot only write styles for a specific layout, this is especially true for skin-changing products such as Weibo. If the module needs to write many styles or even modify the structure under different skin styles, the creation of this module fails; the second principle is the separation of layout and content. A location in the layout does not have to be placed with only some content. In turn, it can be understood as the flexibility and reusability of the module.

　　Second, observe the principles of collaborative development.This specification can include the file directory structure, file and style naming rules, image sprite specifications, module division and call specifications, etc, for example, we define the file directory depth, the public style usage, the module style name uniqueness, and the module File Name and style name must be consistent, ensure that modules produced by all users are unified and standardized. Front-end framework sharing

　　The principle of dividing modules by structure presentation.This is a big difference from Modular programming. In programming development, modules are usually divided based on functions, while in page building, sometimes modules with different functions have the same style. To achieve the maximum reuse of the module style, modules cannot be divided by function. Simply put, what modules have the same appearance structure, we can classify them into a module. Taking the module on the Right of Weibo as an example, the "people who may be interested" and "recommendation application" modules look the same, they are all pictures on the left, text on the right, and functional buttons. They are the same style module.

　　Module stability principle.I often ask new people a question: "How do you think the quality of the code you write is better than the average person ?", Most people will answer questions in compliance with semantics, reduce unnecessary nesting, and try to streamline the code as much as possible. Semantics and code streamlining are important aspects of quality evaluation, but I think whether the Code considers the rationality of Data traversal and the operability of dom nodes, whether or not to consider the damage-resistant behavior caused by expansion can better reflect the level of a page building engineer.

　　Module self-adaptability principle.It refers to the adaptive implementation of width and height of any module. Do not set the width and height of the module in special cases, the plug-and-play function of modules created based on this principle is an important prerequisite for efficient page splicing. If the width of each module is defined, you must redefine attributes such as width, height, and margin of each module in different la s to adapt to the current layout.

　　The Margin-bottom principle.Generally, the webpage layout is a top-to-bottom stream layout (the multi-column structure can also be seen as the stream layout in each column). Therefore, we can set a margin-bottom for each module, to achieve the purpose of unified spacing, avoid setting the top margin for some modules and setting the bottom margin for some modules. (The left-right spacing is usually set by the layout frame style)

After setting up the standards and principles of teamwork, it does not mean that you can start your work in full accordance with your ideas. There are many teams to cooperate with each other, except within the team, support from other teams is also indispensable, so the following two prerequisites are required:

　　The design must strictly follow Rasterization.The module is independent, but the final module is nested in the layout, because our final output is a complete static page, how can we split the module in the shortest time, create a page that meets the designer's intent and product requirements? Rasterization is a fast guarantee. In a layout frame strictly designed according to the Rasterization, engineers only need to set the layout frame style and the internal and external spacing of the column, the subsequent work only requires nesting the modules used on the page, and then calling the corresponding module style. Due to the self-adaptability of the module, when all modules are fully prepared, it usually takes several minutes to splice a page. Front-end framework sharing

　　Unified product, design, and interaction specifications.It is usually easier to unify products and designs in a certain stage of a project. However, if the product and design are in different stages of the same project, it is not a simple task to standardize and unify different projects or products. When there is a problem with standardized uniformity, modularization only stays in a certain project level. Each time a new function is added and new content is added, a new module style needs to be added, reducing portability and reusability, cannot make full use of the expected results. Of course, products are constantly changing and innovative. We cannot require a product to be designed in accordance with a certain specification. However, we should work together to find a win-win solution for each stage. On Weibo, after a long period of effort by all parties, especially the interaction design, integrated the product function components. The WDL standardized library constructed is of great help to our modularization.

According to the actual situation, it is often not smooth sailing to meet all the conditions met, especially the fulfillment of the second condition. However, in a back-to-end way, even if modularity cannot be used to exert its maximum energy stably for each project or product in a long term, modularization can at least improve the efficiency of the team in each project task.

After everyone's efforts, we may still encounter various problems when all the conditions are met and the modular working methods can be smoothly carried out by the team, an unavoidable problem is: module changes caused by product function upgrades. Is it a change to the original module or a new module? Second, the degree of module division. In some cases, the presentation and functional division of modules are vague. In some cases, whether some content is classified as public style, module, or page-specific content is wise; third, the classification of modules. In what way is classification easy to find? There are still many similar issues. In different projects and situations, we need to analyze specific issues, give full play to the team's wisdom, and find the most appropriate solutions. Front-end framework sharing

Although you may encounter various problems during the implementation process and the resistance between team cooperation, you will fall in love with it when you gradually adapt to this modular team building approach! When your team completes every task efficiently, people will fall in love with your team!

Mobile web Front-end development page reconstruction Layout

In this case, the screen size of a mobile phone is large and small, and the mobile web is best made into a responsive layout, that is, an adaptive screen without fixed width and height. In this way, the screen can be normally displayed on all mobile phones. Ico can use font icons. Currently, most mobile browsers support html5 and css3.

What is the difference between web page reconstruction and web development front-end?

Personal Understanding:
Web page reconstruction focuses on the design of user experience, where to put something, where to click and what effect it will be. And so on;
The front-end of web development is more involved in development and code writing. These functions are implemented on the basis of the previous design.

So, one is the user experience designer and the other is the front-end developer.