I finally know why the front office isn’t working overtime…

Abstract:How to build front-end components and even pages quickly and efficiently is an important sign to liberate front-end productivity. It is what every front-end should know to master abstract components and page models, understand front-end visual construction ideas, get rid of the inherent development mode, and improve front-end development efficiency.

This article is shared from the Huawei Cloud Community “[Cloud in Co-Create] Front-end Visualization Framework How Was It Made?” , originally written by Hu Qi, Huawei Cloud EI expert.

With the rapid development of the mobile Internet and the popularization of 5G technology, the demand for front-end pages has exploded, and user interaction has become more and more complex. The cost of developing pages from zero has also risen. How to build front-end components and even pages quickly and efficiently is an important sign to liberate front-end productivity. It is what every front-end should know to master abstract components and page models, understand front-end visual construction ideas, get rid of the inherent development mode, and improve front-end development efficiency.

Let’s start with a chestnut

In our front-end development process, we may often encounter scenarios like this:

(One day, the product manager finds the front end.)

Product Manager: Simply create a welcome page and display "Welcome to". (This is not difficult ah, the code is easy to write, so the front end without thinking about the code show.) Front-end: ' ' '<template> <div> Welcome to </div> </template bb3' ' '(A day later, the product manager felt the welcome was not specific enough and wanted to add a subject, so...) Product Manager: That greeting was simply changed to "Welcome to our website". Front end: </div> </div> > Welcome to our website </div> </template> > (After code submission, code review, code merge, deployment to test environment, test validation, grayscale release, product validation, release online etc.) Another day later, the product manager decided that the welcome didn't showcase our strengths and added an adjective to describe our site.) Product Manager: That greeting still doesn't work. Change it to "Welcome to our cool website." (Forced by a 40-meter knife in the hands of the product manager, the front end changed the code despite the question mark.) Front-end: ' ' '<template> <div> > Welcome to our cool website </div> </template>' ' '(Another day later, the product manager came up with an adjective "crazy cool", so...) Product Manager: Change the welcome message to "Welcome to our awesome website". (At this time, the front can not sit still, thought of through the product manager to maintain the JSON file, in the page to obtain the JSON title field for rendering display)  ``` <template> <div> {{title}} </div> </template> <script> import axios from "axios"; export default { data() { return { title: '' } }, created() { this.queryTitle() }, methods: Then (res=>{if(res && status === 200) {this.title = res.data.title}})} After another day, the product manager has another idea, this time not to change the welcome speech. Product Manager: I'd like to add a selection box to collect user information. (At this time, a gust of wind blowing, the front end in the wind messy......)

Of course, since it can be configured through JSON, it means that the entire component and page can be configured. As long as the product manager is given a visual interface to configure, the page that the TA wants can be generated, which greatly saves the communication cost and improves the development efficiency. This is where the visualization framework comes in.

The composition and division of the visual framework

What does the visualization framework look like? First let’s take a look at the composition and division of the visual framework. As the maintainer of the visual framework, development can provide a visual configuration platform. The target audience is the users of the visual platform, such as the product manager in the above example; Users configure the page through the visual configuration platform, and the platform will produce a configuration file to describe the page and upload it to the storage space. The configuration file is parsed by the rendering engine to eventually generate the page. In this composition, as defenders of the framework, we only need to pay attention to visual configuration platform and rendering engine, of course, the visual configuration platform is only to the user’s input into rendering engine to parse the configuration file and upload, is one of the icing on the cake, if you want to apply in more complex scenarios, you can also add permissions management, For example, A can only edit the pages that A is responsible for, and B can only edit the pages copied by B. It can also implement the process choreography of A workflow, such as auditing…

At the heart of the visualization framework is the rendering engine, how we come up with that rendering engine and how the rendering engine works and renders the final page is all we care about. How to get the rendering engine has to talk about the page generalization model.

Page generalization model

Why is there a page generalization model? Since our different pages are actually rendered by the rendering engine parsing different configuration files, the rendering engine needs the ability to generalize. For example, page A is for form filling, which requires the rendering engine to parse the form’s configuration file. For example, if page B contains a card-like list, you would require the rendering engine to parse the list’s configuration file. The establishment of the page generalization model is mainly based on the developer’s own experience and methods to establish a model to meet their own business needs. As in the above case, if the product manager had been asking only for changes to the welcome, the rendering engine for the title section in the case would have been sufficient to meet the requirements. Next, take Huawei cloud official website page as an example, throw a brick to talk about how to build the page generalization model.

We can see from the screenshot above that this is actually a top-down structure, which can be understood as the page is composed of floors, which can be understood as a DIV block under the body or a function block. For example, from top to bottom, there are headers, banners, guide jump floors, recommended articles, and technical field floors. Of course, the pages we often encounter are not all up and down structure, there are left and right structure.

In fact, with the left and right structure of the page like this, you can understand that there is a larger container component wrapped around the outer layer, forming a whole floor. Container components are only responsible for the style. For example, in the image above, the container components are responsible for the left and right layout. If you have no idea about the layout, you can press the F12 key to view the code in the image above. The two modules on the right are wrapped in div with classname edu-index-version-right, and they are still from top to bottom floors. Therefore, pages = floors + container components.

Deconstruction, take a look at the floor above the graph example, main part is a TAB in figure functional components, by viewing the page source code, we found that the two red box circle of text and no design in TAB functional components, but become the text control alone, this is because this part is belong to the customized function, is not each TAB functional components, I’m going to pull it out and follow the single responsibility principle, the blue box is a container component. Take a look at the cards in the Tab functional component. Cards are also made up of individual controls. Therefore, floors = container components + controls.

The controls in the visual framework, like the components in the common UI framework, all have a complete and single responsibility. For example, the table component, no matter how much function is added, is inside the table, and the function inside the table cannot be separated. But visualization framework of controls and components or is there a difference in the UI framework, the main difference is that control is needed to be edited, so it has a unified props, all controls should follow the same props, such as view configuration and data sources, in the visual we don’t know which kind of components are used page, therefore need a unified to do render loop, Is not aware of the specific properties of the control.

Container components in the visual framework are also components in nature and are mainly responsible for layout. They can be divided into basic container components and functional container components. The left and right layout of the underlying container component is generally implemented through raster or Flex, and the top and bottom layout is implemented through normal text flow or positioning and the spacing of the control itself. Functional container components such as TAB container, round cast components, etc.

When considering user interaction, events have to be considered in the visual model. Events in the visual model need to pay attention to the initiator of interaction, the actor of interaction and the influence way of interaction, but need not pay attention to the type of interaction and the specific content of interaction. For example, when a button is clicked, the maximum and minimum values of the stepper change from 1, 2 to 3, 4, which actually changes the min and Max properties of the input control. For example, after a certain condition is added to the table filter, the display data becomes less, because the triggered data event affects the data source of the table; For example, a switch component that controls the display and hide of a control when clicked…

In the end, the visual model we identified is the point summarized in the figure above. Visual page is composed of control + container component + event. The granularity of control is the smallest unit of function. Container components are responsible for layout and are collections of styles. Event response to user interaction passes dependencies between controls. So how do controls, container components and events come together? I have to talk about the rendering engine.

Rendering engine

The rendering engine is also a component in nature. Its main function is to render the components of the current layer, deal with the interaction relationship of the components of the current layer, and manage the state of the components of the current layer. It does not care about sublayer components, which are rendered by the rendering engine of the sublayer container, because each layer component has a different configuration and data source and therefore renders differently. The sample code for the view section (based on Vue.js) is as follows:

<template>
    <div :class="clsPrefix">
        <component
            :is="component._type"
            v-for="component in viewConfig.components"
            v-show="showState[component._id]"
            :ref="component._id"
            :key="component._id"
            :viewConfig="component"
            :dataSource="dataSource[component._id]"
            @valueChange="valueChangeHandler($event, component._id)"
        />
    </div>
</template>

The outermost layer is wrapped by div, which defines the rendering engine in the way of the custom dynamic component component. The property with underline means the built-in property of the custom component. Is determines the rendering type of the component, such as button, so that you can render the component without knowing the specific content of the component in the layer. V-for loops the properties of the current component; V-show controls whether the component is displayed, and performs state management through showState; Ref establishes indexes, which can be used to do some advanced functions, such as parent container calling child container methods; ViewConfig and DataSource are required in the controls mentioned above; ValueChange is a unified event submitted by the component.

Both parent and child containers are essentially rendering engines, but in different styles. For example, a container component with a left/right layout is equivalent to binding a class like a raster layout or a Flex layout to the v-for loop in the view. For a raster layout, the user needs to define Type as a raster component and then configure the grid property in ViewConfig, etc. For a Flex layout, the user needs to define Type as a raster component. The type defined is the Flex component, with alignment specified as space-between or something like that. The sample code above is a normal top-down layout.

First, the outer layer passes two key parameters –viewConfig and DataSource — and then the layer container performs configuration parsing and configuration distribution. Configuration parsing mainly includes property mapping and generating events. Property mapping, such as the title property needed by the control itself, may be called the label property in the configuration file. In this case, we need to convert the label to the title property, but the conversion logic is not contained in the rendering engine, it just calls the externally wrapped method. Generate events by generating a default event based on the configuration and mounting it. Before configuring distribution, the parent state of the resolved configuration will be initialized and placed in the parent layer, mainly considering that viewConfig and DataSource are not assigned synchronously, and need to wait for both are ready for distribution.

In the introduction to controls, it was mentioned that each control should be committed because each control cannot be an Origin of another control. For example, the Tip component, although it may not interact itself, may become a dependency of other controls, the sublayer may need to fetch the content, the sublayer container’s referrals are collected in the parent container’s valueWatch, after the sublayer container has been submitted, if the state changes, The parent container will loop through the events executed according to the FunctionList; If it is a display event, the parent showState control display or hide is updated. If it is a data event, the viewConfig and DataSource are changed to perform a reassignment on the target. In general, the rendering engine process consists of four steps: configuration parsing, configuration distribution, collection of submissions, and launch of events.

conclusion

In order to reduce the amount of code for page development and improve the code reuse, we expect the page to be able to perform visual editing; In order to get a visual framework, we carried out visual modeling analysis on pages, and concluded that almost all pages can be composed of controls and container components, and the user interaction and the cascading relationship between components can be handled through generalized events. According to the modeling results, a rendering engine is established to support the whole process and finally achieve visualization.

This article is edited from the second phase of Huawei Cloud Community Content Co-creation Activity[Live streaming] 2.0-fold start? Finish the front page efficiently.

To view the event details:https://bbs.huaweicloud.com/forum/thread-111494-1-1.html

Click on the attention, the first time to understand Huawei cloud fresh technology ~