As a development mode, componentization has been widely recognized in code reuse and improvement of development efficiency. Componentization is applicable to the development of mobile terminal, Web front-end, PC terminal, TV terminal and other types of client and front-end.

This paper mainly describes how iQiyi knowledge WEB front-end team combined with their own business characteristics, explore and practice a set of efficient front-end componentization scheme.

Componentization: front-end decoupling and efficiency booster

In the process of front-end business development, the volume of code will become bigger and bigger, and the logical complexity of the business will become more and more complicated with iteration.

Componentization is about efficiency, delivering products that are usable, intuitive, and composable business forms. At present, front-end componentization in the industry can be roughly divided into 3 categories according to users: ** For operation personnel: * * operation personnel page creation, design, main components like lego blocks, together, in view of the special components, can customize to developers implement, implement some partial static or partial fixed function (such as lucky draw, q&a, payment, etc.) of the page, all companies generally have Low Code platform of similar products.

** For designers: ** Designers are mainly involved in page design, and directly convert the design draft into front-end code, eliminating front-end development process, such as ImgCook by Ali, or for some complex logic, it can be handed over to developers for secondary development.

Developer-oriented: This is also the most traditional development mode, mainly for dynamic pages, the back-end interface needs to cooperate with the scene, the components of each page common, so remove the common components for each page to call. The componentized design of iQiyi knowledge belongs to the third kind, which is designed for developers. At the development level, the reuse of components can reduce redundant code, realize the decoupling of function and business logic, and improve scalability and maintainability through the expansion of components.

Business scenario: Multiple and independent projects with product consistency

As for component splitting, there is no unified standard in the industry. It needs to be based on specific business scenarios, because the intensity and degree of component splitting may vary in different scenarios.

Iqiyi knowledge WEB front-end project composition

As can be seen from the composition of iQiyi knowledge WEB front-end projects, there are a lot of knowledge WEB front-end projects. We separate the projects by type, and the projects under each category are independent projects to complete their related business functions. Each project is independently developed and deployed, and there is no direct business relationship between the projects. Project though, but the project has a business related course, lecturer, shops and other entities, and these entities UI style in various projects to basic consistent, other general UI elements, such as box, loading, etc, are to ensure that the style is consistent, so in order to product experience consistency, while increasing the development efficiency, enhance code reusability, Components need to be removed from the Web front-end.

Simple need to explain here, our Web side modular thinking and knowledge of mobile team in modular way of thinking is not the same, more mobile end from the longitudinal component of the business and function division, can also be called a modular, each component or module includes both the UI and include business logic, such as player component broadcast playback controls and UI style, The sharing component includes the sharing function and popup window, and the payment component includes the payment process and the payment result page at the cashier desk. The componentization of the Web front end is more focused on the UI level, and the logic is more placed in the page, which is also in line with the characteristics of Web development, and the UI elements are more reusable.

Interested students can learn about the design ideas of mobile terminal componentization, portal is here: IQiyi knowledge mobile terminal componentization exploration and Practice.

Based on the above background, the knowledge Web front-end is constructed with the following objectives:

1. Code reuse to improve development efficiency. Divide components horizontally and vertically according to business characteristics, and take components as units to meet business requirements. Although UI components are the main component, vertical component extraction is also carried out for relatively independent functions. 2. Independent development and maintenance of components, decoupled from each project components are independently developed, debugged and released for the business side to call, business side only need to focus on the business itself. 3. For more convenient component invocation and more reasonable route jump component invocation, input and output parameters should be specified, and parameters should be verified and reasonable error prompt should be given; When a jump is involved in a project reference to a business component, the component library automatically determines whether it is an in-project (front-end routing) jump or an out-of-project (location.href) jump. 4. Components are documented to support online debugging and reduce the threshold of using components. The component library needs to have perfect usage instructions and supports online debugging, making it easier and convenient for business parties to use.

The overall design

The design of any tool needs to start from the actual business scenario. Back to our scenario, it becomes very important to consider how to manage the common component resources that depend on between projects. The design of components should not only meet the convenience of the business side, but also meet the maintainability and scalability of the development of components themselves.

In our opinion, the key of componentization lies in the layering and splitting of components. It is very important to define the hierarchy of components and the definition of the hierarchy for componentization system. Based on our own business, we layered the components as follows (diagram) :

For a better understanding, we show the relationship between the levels as follows (diagram) :

Since the Card component consists of multiple Item components, the relationship between Card component and Item component is as follows:

Card components

Based on the above design, we can summarize the components by category: basic components, business components. The basic components can be divided into: basic UI components, basic tools components; Business components can be divided into item components, Card components, block components, functional components, page components.

Based on the component

• Basic Tool library: This is a set of JS library with no UI interface, including basic functions used by the project, such as network request, page burying point, abnormal reporting, CallNative interaction with Native, and some common utility tools, etc.

• Basic UI components: including: text, image, button, layout, loading, toast prompt and other commonly used UI components.

The business component

• Item component: the smallest unit of a business component, such as an Item in a list, an Item in a grid, an Item in a diamond position, an image in a rotation chart, etc. The business can import or combine the required Item components to complete the presentation of the page.

• Card component: this is a set of components corresponding to carding. Here is a brief introduction to carding: Back end returns a set of card-based data structure. Each Card data corresponds to a UI component of the front end one by one. Item component can also be part of Card. Card component combines multiple Item components to display the interface.

• Block component: a component that is removed to complete the UI display of a block and used by the business side, such as comment component and evaluation component.

• Functional component: a component removed to complete a specific business function, such as player component, publisher component, sharing component, etc.

• Page component: Also called routing component, this is based on the micro front end to pull out the component, one of our pages can also be used as a component, so that other projects can use.

The technical implementation

Since basic component, block component and functional component are very common designs, we focus on Card component and Item component in business component. It is important to note that both basic and business components need to be designed in accordance with the following design principles from the beginning.

Design principles

Our component design principles should meet the following requirements:

• The technology stack needs to be unified to ensure that components are in the same technology ecosystem.

• Single responsibility, a component that focuses on doing one thing and doing it well.

• The pursuit of no side effects, once the input is certain, the output is fixed.

• Configurable, a component knows what its inputs and outputs are, and the entry checks the validity of the parameters.

• The granularity is moderate. The size of the granularity needs to be balanced based on the actual situation. If the granularity is too small, the maintenance cost will increase; if the granularity is too large, it is not flexible and has high reusability. Each component should have its own unique partitioning purpose, either for reuse or for encapsulation complexity to achieve business clarity.

• Appropriate package size for quick page loading.

• Complete instructions for use.

Data protocol

At the beginning of the project, our HOME page of H5 mobile terminal: Zhishi.m.iqiyi.com is based on the card-based data of the backend, and the backend data selects the front-end Card component and Item component to display the page. In this scenario, our Card component and Item component are designed first. At the same time, we design a set of front-end data protocol (which can be understood as data format definition). After the front-end protocol, the back-end Card data is converted into the front-end Card data structure, and on the basis of this data structure, Card component and Item component are extracted.

Later, we found that a large number of our pages are not based on card-based data, but on different apis, different data structures, how to make these pages also reuse our Card component, Item component? Therefore, we need different converters to convert the back-end interface data into the front-end data format according to the front-end data protocol (as shown in the figure below). In this way, no matter how the back-end interface data changes, we only need to change the logic of the converter without changing the front-end component code, and then reuse our Card component and Item component.

The UI implementation

In terms of specific UI implementation, we take two examples of items commonly used in our business UI component library in the figure: course list Item and course palace Item.

It’s not hard to see that the Item component is mainly composed of images and text, which happen to belong to our basic UI component library.

• Image component, on the premise of retaining the original ‘IMG’ features, support lazy loading, custom placeholder, loading failure placeholder, image acquisition strategy (webP or JPG);

• Text component that supports single-line and multi-line truncation.

Therefore, when we write Item components, we only need to combine pictures and text components. In this way, as the number of components increases, it will be very easy when we develop other Item components and the efficiency will be greatly improved.

Another point to note is that our components may need to meet the normal display of mobile phones, tablets and PCS at the same time, which will involve the issues of layout and screen adaptation, as well as the dynamic change of screen size caused by device rotation. Therefore, in the design of the component, the width and height can not be fixed, but set by the reference party. At the same time, we need to accommodate the adaptation style of different screens in the component, and we can also export the adaptation style file of different screens for the reference party to use.

Build tools

Since the base library is a set of JS libraries, we built it using Rollup, an efficient library module wrapper that makes our components lighter and simpler, while generating ES, UMD files for the front end to call.

UI component library, we use VUE as the front-end technology stack and Webpack for construction. Business component project supports exporting multiple component entries and loading business components on demand (as shown below).

Component support for on-demand loading means that each component entry needs to be packaged separately, which involves the problem of double referencing common resources for each entry.

We can use @babel/runtime, @babel/plugin-transform-runtime, and set core-js to false to minimize the size of the Babel transform package.

Use the Babel command to pack JS files (without webpack) to reduce the JS package body.

Use webpack Externals to pull out third-party dependencies, as well as common references for each component, by requiring them, rather than repackaging them into each component.

Technical documentation

The completion of our component library development does not mean that componentization is finished. A good component library usually requires a good documentation, which will reduce the communication cost of team members. Therefore, we built a UI component documentation site based on storybook, such as the basic UI component library document in the following figure. The latest component version can be displayed dynamically, and UI component debugging can be supported online, which can more intuitively express component style and interaction, and enhance the ease of use of components.

conclusion

Front-end component libraries are typically placed in a company’s private repository, maintained through NPM, and referenced and packaged by users into their own projects. With the popularity of Webpack5 Module federation, components can also be distributed as micromodules, which can be referenced by dynamic load modules.

From this, we can also see the advantages of front-end componentization: it can greatly reduce the coupling of various functions of the system, which is of great benefit to front-end engineering and reduce the maintenance cost of the code.

After continuous improvement and iteration, iQiyi Knowledge WEB front-end component library has basically realized all the objectives of componentization. Through independent development, testing and release of components, each business project only needs to pay attention to its own business, and components have been fully reused. Componentization has been successfully applied to each business project.

Componentization is not an overnight process, but a continuous process. For example, as there will be many business components, business components need to support business parties to load on demand. At the same time, the package size of the components should be considered. Business components should be distributed uniformly through Jenkins like tools, automated testing should be conducted prior to release to achieve good test coverage, etc.

Of course, in the actual development work, there will be many unsatisfactory situations, such as a small project does not have so many duplicate codes, such as the design team does not recognize componentization and so on, so componentization needs to consider the specific business scenarios, on this premise, it is necessary to design our own componentization system.