With the rapid development of mobile Internet and the popularization of 5G technology, the demand for front-end pages has exploded, user interaction has become more and more complex, and the cost of developing pages from zero is also rising. How to quickly and efficiently build front-end components and even pages is an important sign of liberating front-end productivity. Every front-end should know how 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.
Start with a chestnut
In our front-end development process, we may often encounter scenarios like this:
(One day, the product manager came to the front end.) Product Manager: Simply create a welcome page and say "welcome to visit". (It's not that hard; the code is easy to write, so the front end shows it off without thinking.) <template> <div> Welcome to </div> </template>. Product Manager: That welcome was simply changed to "Welcome to our website". Front end: </div> </template> welcome to our website </div> </template> (through a series of processes such as code submission, code review, code merge, deployment to the test environment, test verification, gray release, product verification, release online, etc., the welcome message is finally updated... A day later, the product manager decided that the welcome didn't capture our strengths and added an adjective to describe the site.) Product Manager: That welcome message still won't work. Change it to "Welcome to our cool website." (The front end changed the code, despite the question marks, because the product manager had a 40-meter knife in his hand.) </div> </template> (another day later, the product manager came up with an adjective for "cool", so...) Product Manager: Change the welcome to "Welcome to our awesome website." (At this point, the front end can not sit, thought of letting the product manager maintain the JSON file, get the TITLE field in the JSON page for rendering display) front-end: ``` <template> <div> {{title}} </div> </template> <script> import axios from "axios"; export default { data() { return { title: '' } }, created() { this.queryTitle() }, methods: {queryTitle() {axios.get('JSON file path '). Then (res=>{if(res && res.status === 200) {this.title = res.data.title}})} (Another day later, the product manager had another idea, this time not to change the welcome message.) Product Manager: I'd like to add another selection box to collect user information. (At this time, a gust of wind blowing, the front end in the wind messy......)Copy the code
Of course, since we can think of configuring through JSON, it means that the entire component and page can be configured. We only need to give the product manager a visual interface to configure, and then the page he or she wants can be generated, which greatly saves the communication cost and improves the development efficiency. This is where the visual framework comes in.
Visual framework composition and division of labor
What is the visual framework? First let’s take a look at the composition and division of labor of the visualization framework. As the maintainer of visual framework, development can provide a visual configuration platform; The target audience, the users of the visualization platform, such as the product manager in the example above; 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 generate the final 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 realize the process orchestration of A workflow, such as auditing… The core of the visualization framework is the rendering engine, and how we arrive at that rendering engine and how it works and renders the final page is what we care about. How to figure out the rendering engine has to start with the page generalization model.
Page generalization model
Why is there a page generalization model? Because our different pages are actually rendered by the rendering engine parsing different configuration files, the rendering engine needs the ability to generalize. For example, if page A is A form fill, the rendering engine is required to parse the configuration file of the form. For example, if page B contains a list of cards, the rendering engine is required to parse the configuration file of the list. The establishment of 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 case above, if the product manager keeps asking for changes to the welcome message, the rendering engine for the title section in the case will suffice. Next, take huawei cloud official website as an example to talk about how to establish the page generalization model.
From the above screenshot, we can see that this is actually a top-down structure, which can be understood as a page 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, jump floors, recommended articles, and technical domain floors. Of course, we often encounter pages that are not all up and down, but also left and right.
In fact, with pages like this left and right structure, you can understand that there is also a larger container component wrapped around the outer layer, forming a whole floor. Container components are only responsible for style. For example, the container components are responsible for left and right layout. If you have no idea about layout, you can press THE F12 key to see the layout 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 the floor from top to bottom. 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 pulling it out and following the single responsibility principle, the blue box is a container component. Take a look at the cards in the TAB function component. The cards are also composed of controls one by one. Therefore, floor = container component + control.
Controls in visual framework and common UI framework components, have perfect and single responsibilities, such as table components, no matter how to add functions are in the table, the table inside the function is unable to split out. However, there is a difference between a control in a visual framework and a component in a UI framework. The main difference is that the control needs to be edited, so it has a uniformprops
, all controls must follow the sameprops
For example, view configuration and data source, we do not know which components will be used in the page in the visualization, so we need to do the loop rendering uniformly, not aware of the specific properties of the control.
The container components in the visual framework are components in essence, which are mainly responsible for layout. They are divided into basic container components and functional container components. The left and right layouts in basic container components are typically implemented through grids or Flex, and the up and down layouts are implemented through normal text flow or positioning and spacing of controls themselves. Function container components such as TAB containers, multicast components, etc.
When considering user interactions, events have to be considered in a visual model. Events in the visual model need to focus on the initiator of interaction, the actor of interaction and the way of interaction influence, rather than 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 or 2 to 3 or 4input
The control ofmin
andmax
Properties; For example, when certain conditions are added to table filtering, less data is displayed because data events are triggered to affect the data source of the table. Like a switch component that can be clicked to show and hide the controls…
Finally, the visual model we have identified is the point summarized in the figure above. Visual pages are created byControl + container component + event
Composition, control of the smallest particle size, is the smallest unit of function; Container components are responsible for layout and are collections of styles; Event response user interactions transfer dependencies between controls. How do controls, container components, and events come together? We have to talk about rendering engines.
Rendering engine
The rendering engine is also a component in essence. Its main function is to render the component of the current layer, deal with the interaction of the component of the current layer, and manage the state of the component of the current layer. It does not care about sublayer components, which are rendered by the rendering engine of the sublayer container, because each component has a different configuration and data source, and therefore a different rendering result. 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>
Copy the code
The outermost layer is wrapped by div, which defines the rendering engine in the way of custom dynamic component. The underlined attribute means that it is the built-in attribute of the custom component. Is determines the type of component rendering, such as button, so that the specific content of the layer component can be rendered as the layer component. V-for loop properties of the current component; V-show Controls whether components are displayed. The showState command is used to manage the status. Ref creates an index, which can be used for some advanced functions, such as the parent container calling the methods of the child container. ViewConfig and dataSource are required for the controls mentioned above; ValueChange is a unified event submitted by the component.
Both parent and child containers are essentially rendering engines, just in different styles. For example, a container component with a left and right layout is equivalent to a viewv-for
The loop is bound to oneclass
Like grid layouts orflex
The layout style, if raster layout, must be defined by the user firsttype
Is the grid component, and then configureviewConfig
In thegrid
Property or something like that, if yesflex
Layout, definedtype
isflex
Component, aligned as specifiedspace-between
And so on. The example code above is a normal top-down layout.
First, the outer layer passes two key parametersviewConfig
anddataSource
When the layer container does configuration parsing and configuration distribution. Configuration resolution mainly involves property mapping and generating events. Property mapping, such as the control itself, requires the title property, which may be called in the configuration filelabel
Property, and we’re going to putlabel
Converted totitle
, but the conversion logic is not included in the rendering engine, just calls externally wrapped methods; Generated events are generated and mounted according to the configuration. Before configuration distribution, the resolved configuration will be initialized and the parent layer state will be stored in the parent layer, mainly considering thatviewConfi
G anddataSource
Instead of synchronous assignment, wait until everything is ready to distribute.
When I introduced controls, I mentioned that each control should be committed, because each control cannot be one of the other controlsorigin
. Such asTip
Components, although they may not interact themselves, may become dependencies of other controls, child layers may need to fetch content, and references from child containers are collected in the parent container’svalueWatch
If the state changes after the child container commits, the parent container will change the state according to the child containerfunctionList
De-loop events; If it is a presentation class event, the parent level is updatedshowState
Controls show or hide and changes if it is a data-like eventviewConfig
anddataSource
To perform a reassignment to the target. In summary, the rendering engine process consists of four steps: configuration resolution, configuration distribution, collection commit, and event initiation.
conclusion
In order to reduce the amount of page development code and improve the reuse of code, we expect the page can be visual editing; In order to get a visual framework, we analyze the visual modeling of pages, and conclude that almost all pages can be composed of controls and container components, and handle the user interaction and the cascade relationship between components through generalized events. According to the modeling results, a rendering engine is established to support the whole process and finally realize the visualization.
This article is collated from the [online live broadcast] 2.0 times of huawei Cloud community Content co-creation activity phase ii. Finish the front page efficiently. View the event details: bbs.huaweicloud.com/forum/threa…