This article is the second article in the article series ” Let’s talk about front-end UI components “. The content is related to the previous article in this series ” Let’s talk about front-end UI components: core concepts “. If you haven’t read it yet, it is recommended to read it.
The main content of this article is to model front-end UI components based on characteristics, so that we can understand all aspects of it as fully as possible and lay the foundation for how to design and build a component system.
Contents
Component composition
Decompose UI components from the perspective of separation of concerns and analyze the variability of each part.
Components
The composition of a complete functional UI component has three aspects: structure, presentation and behavior. Why emphasize “complete functional UI components”? This is because it is the most comprehensive set of features, while other “UI components” may lack some features, making the analysis less complete.
Seeing the three words “structure”, “performance” and “behavior”, as an experienced front-end developer, it is natural to think of the separation of concerns in front-end development that has been advocated a long time ago – HTML Responsible for organizing the page structure, CSS is responsible for the presentation style of web page content, and JS is responsible for the interaction between users and web pages. They each play different and complementary roles.
However, here, their meanings will be different –
It is true that the web page content organized by HTML is “structure”, but it is only a structure at the code level and is not affected by CSS. The final visual presentation, that is, the “structure” at the visual level, should also include CSS layout styles, such as positioning, float, etc.
Those non-layout styles in CSS, such as colors, fonts, text, borders, sizes, whitespace and other categories, as well as icons and pictures, are all “expression”. These are also commonly referred to as “themes” or “skins”.
The event system that can be run in JS and the functions and object methods for logical processing are considered “behaviors” – this is the interaction logic of UI components. Of course, business logic integrated with interaction logic is also part of “behavior”.
variability
Depending on the nature of each part that makes up a UI component, it will affect the volatility of the corresponding part of the UI component – whether the part is relatively stable or relatively unstable for component reuse.
GUI has been developing for decades, and the graphical elements and layout methods of human-computer interaction have been relatively fixed. As long as there are no revolutionary interactive devices like Google Glass, there will be no major changes.
Ole ” Let’s talk about template-oriented front-end development “
As mentioned above, it is impossible to know what kind of revolutionary interaction methods will appear in the future, but I think that as long as you need to use your eyes to see and use your hands to operate, the interaction methods cannot escape the changes that have not changed in the past few decades. form. Therefore, the visual structure and interaction logic of UI components are the least volatile, and both interaction modes and triggered events are enumerable.
If you look purely at the final HTML structure, it is considered immutable. However, in modern front-end development, the structure of HTML is basically dynamically generated and strongly relies on JS libraries/frameworks such as React and Vue that do not have unified standards. . In addition, there are platform-limited view structure description languages such as WXML and AXML . Due to inconsistent writing, the content structure of the page becomes less stable.
Generally speaking, things that are closer to the user are more likely to change. In websites and applications, the closest thing to the user is the GUI, and the closest thing to the user in the GUI is the theme style, which is the most intuitive thing for the user. The theme style will change with the aesthetics and ideas of the GUI designer (usually a designer), so it is the most volatile.
Because business logic is the core of business-related processing, if the business rules change, the corresponding code implementation must also change, so business logic is also very volatile. Business logic is very necessary and important for a website or application, but for UI components, it is not so necessary, let alone important. At the front-end GUI level, business logic should be an extension of interaction logic.
For convenience, the variability of each component of the UI component and its influencing factors are organized as follows:
| constitute | variability | Influencing factors | |
|---|---|---|---|
| structure | visual structure | Unchangeable | Content structure, layout style |
| Content structure | More volatile | Source code of JS library/framework that generates HTML, platform-specific view structure description language | |
| Performance | theme style | Very changeable | Aesthetics and ideas of GUI designers, non-layout styles, icons and images |
| Behavior | interaction logic | Unchangeable | Interaction Designer’s Thoughts |
| Business logic | Very changeable | Business Rules |
As can be seen from the table, “volatility” is divided into three levels, which are explained in order from small to large:
- “Not easy to change” – Affected by the interaction method, it is unlikely to change as long as there are no revolutionary changes;
- “More variable” – affected by source code syntax, as long as the source code is written in a certain way, it will not change;
- “Very changeable” – Affected by business and people, it will not change as long as the business field, business rules and people’s ideas remain unchanged.
Component classification
Classify UI components from a more abstract perspective——
atomicity
From the perspective of whether a UI component contains other UI components, it is divided into two categories: “atomic components” and “composite components”. “Atomic component” is a UI component that cannot be subdivided, that is, it no longer contains other UI components, such as button components, icon components, dividing line components, etc.; “composite components” are composed of more than one atomic component , such as navigation menu components, tab components, dialog components, etc.
Versatility
According to the versatility of UI components, they can be divided into “general components” and “special components”. “General components” are UI components that can meet most common scenarios. Their collection is usually packaged and released as a software package as a “component library”; “special components” exist to solve the needs of certain special scenarios, such as Data grids, various editors, etc. are generally contracted separately.
Feature
According to the role played by UI components, they can be roughly divided into the following categories:
| Component Category | Sample component |
|---|---|
| command input | Button component, drop-down menu component |
| data input | Input box component, radio button component, check box component, drop-down list component, date picker component |
| data output | List component, table component, data grid component |
| Information display | Icon component, loading status component, tooltip component |
| container | Accordion component, panel component, tab component, field set component |
| navigation | Navigation menu component, breadcrumb component, hyperlink component |
| special window | Dialog component, warning component |
This classification method does not have a strict definition, and it depends on people’s opinions.
Component inheritance
Unlike inheritance in object-oriented programming, which is the reuse of behaviors, the “inheritance” mentioned here refers to the reuse of expressions, and it can also be “multiple inheritance.”
Before proceeding, let us first introduce the concept of “virtual components”. As its name suggests, it is a virtual component that does not actually exist and is only a conceptual component. It is a collection of several theme style attributes.
Input box components, drop-down list components, etc. all belong to form controls . They all inherit from the virtual component “form control”. If they do not specify color, font, border and other theme style attributes, they will be based on the virtual component. The settings are displayed. Similarly, drop-down list components, drop-down menu components, etc. all have pop-up layers, and they all inherit the virtual component of “pop-up layer”.
You must have discovered that the drop-down list component inherits the two virtual components of “form control” and “pop-up layer” at the same time. This is the “multiple inheritance” mentioned above.
Those so-called “virtual components” also follow the same inheritance rules – if they do not specify a specific theme style attribute, they will be displayed according to the settings of the parent. So, what is the “parent” of a virtual component? ——It is the basic style.
Although the inheritance relationship described here looks a bit like inheritance in CSS , they are not the same.
Summarize
This article starts from the perspective of the composition, classification of front-end UI components and the inheritance relationship between components, and discusses some points that need to be paid attention to in establishing a component system by analyzing the characteristics of the components. Among them, the variability of each component element of the UI component is the most important thing to pay attention to. It will have a great impact on the reusability and scalability of the component system.
In essence, HTML is at the same level as WXML and AXML, and they are both platform-limited view structure description languages - WXML is for WeChat mini programs, AXML is for Alipay mini programs, and HTML is for the “web browser” platform of.
In dynamic web pages, especially when template engines such as Mustache and Handlebars or libraries/frameworks such as React and Vue are used, the final content structure is basically generated by JS, which strengthens JS and weakens the content structure of HTML. Control.
Each JS library/framework has different HTML code generation methods, different view structure description syntax, and no unified standard, which causes confusion – this is also the biggest challenge to the reusability of front-end UI components!