Detailed explanation of the basic knowledge of front-end componentization

Here we will learn about front-end componentization , which is the most important part of the front-end architecture.

When it comes to front-end architecture, there are actually two hottest topics in front-end architecture, one is componentization and the other is architectural model. The concept of componentization started with the study of how to extend HTML tags, and eventually evolved into a front-end architecture system. And its most important function is to improve the reusability of front-end code .

The architectural pattern is the design pattern that everyone is particularly familiar with, such as MVC , MVVM , etc. This topic is mainly concerned with the interaction between the front-end and the data logic layer.

Therefore, componentization can be said to be the top priority in the front-end architecture. In actual engineering, componentization is often more important than architectural mode. Because componentization directly determines the code reuse rate of a front-end team, and a good componentization system can help a front-end team improve their code reuse rate, thereby improving the overall efficiency of the team .

Because the reuse rate increases, the amount of code that everyone writes repeatedly will decrease, efficiency will increase, and the psychological and mental burden on team members will be much less.

So learning componentization is very important.

Here we start by understanding what componentization is and the basic components of a component.

Basic concepts of components

Components are divided into modules and objects. Components are strongly related to UI, so in a sense we can think of components as special modules or special objects.

Componentization is both對象and模塊

The characteristic of componentization is that it can be combined using a tree structure and has a certain degree of template configuration capability. This is the basic concept of our component.

The difference between objects and components

First, let's look at the object, which has three main elements :

1. Properties
2. Methods
3. Inheritance

A normal object in JavaScript can be described by its properties, methods, and inheritance relationships. The inheritance here uses prototype inheritance in JavaScript.

The "ordinary objects" mentioned here do not include complex function objects or other special objects. In JavaScript, properties and methods are integrated.

Compared with components, components contain richer semantic elements. The elements in components are:

• Properties
• Methods
• Inherit
• Attribute
• Config & State
• Event
• Lifecycle
• Children

Properties and Attribute have very different meanings in English, but they are often translated into "properties". If both words appear, Attribute will be translated into "characteristic" and Properties will be translated into "attribute". How do we distinguish these two elements? We will learn more about this in detail later in the article.

Next is the component's Config , which is a configuration for the component. We often use Config when creating an object in a constructor. The parameter we pass into this constructor is called " Config ".

Components also have state . When the user operates or some methods are called, a state will change. This is the state of the component, which will change with some behaviors. state and properties , attributes , and config may be familiar or the same.

event is the consciousness of "event", and an event is transmitted outward by a component. Our components are mainly used to describe things like UI, and basically they will have this kind of event to implement some type of interaction.

Each component has lifecycle , which will be discussed in detail later in the article.

children are a very important part of a component. children are also a necessary condition in a component, because without children components it is impossible to form a tree structure, and the ability to describe the interface will be much worse.

There were some popular drag-and-drop systems before, where we could drag some pre-written UI components onto the page to build our system interface. But later I found that in addition to being able to drag and drop in certain areas, some automatic sorting and component nesting functional requirements are also needed. At this time, it will not work if there is no tree structure between components.

Finally, components add many semantically related concepts based on objects, which makes components a concept that is very suitable for describing UI.

Component

Let's use a diagram to understand the components more deeply.

The most direct source of changes in components is user input and operations. For example, when a user selects an option in our selection box component, our state and even our children children will change.

The situations on the right side of the figure are the relationships between component developers and components. One of them is that the developer uses the component's Markup Code to affect the component. In fact, developers use component Attribute to change some features or characteristics of components.

Attribute is a declarative language and also標記型代碼Markup Code . And Markup Code is not necessarily an XML-like language like HTML. In the large ecosystem of markup languages, there are actually many languages ​​that can be used to describe the structure of an interface. But the most mainstream one is based on XML system. The most common one in our Web field is XML. JSX can also be understood as an XML structure embedded in a programming language.

In addition to using Attribute , developers can also use Property to affect components. This component itself has Property . When a developer modifies the properties of a component, the component will change. This is the same concept as屬性Property in the object.

Are Attribute and Property the same? Sometimes it is, sometimes it isn't, it all depends on the designer of the component system. The implementer or designer of a component can unify attribute and property . We can even unify state , config , attribute , and property .

Then there is方法method , which is used to describe a complex process, but Property in JavaScript are allowed to have methods such as get and set , so in the end the functions of method and property are similar.

So here we can determine a concept that developers who use components will use method and property , which are the elements of these components. However, if a component developer needs to pass a message to the programmer who uses the component,事件event is needed. When a component triggers a change due to a certain behavior or event, the component will send event message to the user. So the direction of event here is the opposite, transmitted from the component to the outside.

Through this picture, we can clearly understand the functions of each element of the component and the direction of their information flow .

Attribute

Among all the elements of a component, the most complex ones are Attribute and Property .

Our understanding of the English word " Attribute emphasizes more on descriptiveness . For example, if we describe a person as having a lot of hair, being handsome, and having fair skin, these are all Attribute , or descriptions of the characteristics and features of something.

Property is more of a subordinate relationship . For example, during development we often find an object that has a Property that is another object. There is a high probability that there is a subordinate relationship between them, and the child object is subordinate to the parent object. But there is also a special case here. If we have a weak reference, one object references another object, which is a completely different concept.

The above is about the difference between these two words in English, but they are also different in actual application scenarios.

Because Property is a subordinate relationship, it is often used in our object-oriented programming. Attribute was originally used in our XML. Sometimes they are the same, and sometimes they are different.

Attribute vs. Property

Here we use some examples to see the difference between Attribute and Property. We can look at scenarios where they are not equivalent in HTML.

Attribute:

<my-component attribute="v" />
<script>
 myComponent.getAttribute('a')
 myComponent.setAttribute('a', value)
</script>

• Attributes in HTML can be set through HTML attributes
• It can also be set via JavaScript

Property:

myComponent.a = 'value';

• Here is to define a certain element a = 'value'
• This is not an attribute, but a property.

Many students think that these are just two different ways of writing, but in fact their behaviors are different.

Class Attribute

<div class="class1 class2"></div>
<script>
 var div = document.getElementByTagName('div');
 div.className // Output is class1 class2	
</script>

In the early days of JavaScript, Class was a keyword, so early class as a keyword was not allowed to be used as an attribute name. But now this has been changed, keywords can also be used as attribute names.

In order to allow this keyword to be used in this way, a compromise design was made in HTML. In HTML the attribute is still called class but in the DOM object the property becomes className . However, the two are still in a mutually reflective relationship, and this magical relationship will often lead people into some pitfalls.

For example, in React, when we write className, it automatically sets the Class.

Style property

Now in JavaScript language, there is no inconsistency between class and className. We can use div.class . However, HTML still does not support the name class, which is a problem caused by some historical baggage.

Sometimes an Attribute is a string, while a Property is an object that converts the string into a semantic string. The most typical one is Style .

<div class="class1 class2" style="color:blue"></div>
<script>
 var div = document.getElementByTagName('div');
 div.style // This is an object</script>

The Style attribute in HTML is a string, and we can use getAttribute and setAttribute to get and set this attribute. But if we use the Style property, we get a key and value structure.

Href Attribute

In HTML, the meanings of href attribute and property are very similar. But its property is the resolved URL.

For example, the value of our href is "//m.taobao.com". At this time, the previous http or https protocol is based on the current page, so the href here needs to be compiled again to respond to the protocol of the current page.

Those who have done the conversion from http to https should all know that when we make our website use the https protocol, we need to change all the hard-coded http or https URLs to use // .

So whatever we write in href will come out, that is the attribute. If it is resolved, it becomes our property.

<a href="//m.taobao.com" rel="external nofollow" ></a>
<script>
 var a = document.getElementByTagName('a');
 // The result is "http://m.taobao.com", this url is the result of resolution // so this is Property
 a.href;
 // And this is "//m.taobao.com", which is exactly the same as in the HTML code// So this is Attribute
 a.getAttribute('href');
</script>

We can also see in the above code that we can access both property and attribute at the same time. Although their semantics are very close, they are not the same thing.

But if we change either one, it will change the other one . This is a phenomenon that we need to pay attention to.

Input and value

This is the most magical pair, and value is also a special pit.

Many of us think that the values ​​in properties and attributes are completely equivalent. Actually not. The input value in this attribute is equivalent to the default value of a value. Regardless of whether the user enters a value in the input or the developer uses JavaScript to assign a value to the input, the attribute of the input will not change.

When displaying input, property will be displayed first, so the value in attribute is equivalent to a default value. This is a very famous pitfall. If you have used JQuery in the early days, you will think that prop and attr are the same, but you will fall into the pitfall here.

So later the JQuery library came up with a method called val, so that we don't need to think about the value of the attribute or property, we can directly use the val it provides to get the value.

On the one hand, we will enhance our knowledge of HTML property and attribute. On the other hand, it makes us realize that even a labeling system designed by top computer experts can have the problem of two similar attributes not being equivalent. So if we were asked to design a tagging system, would we make properties and attributes equivalent or not? After learning the entire componentized knowledge, let's answer this question together.

How to design component states

Here we analyze the differences between property , attribute , state , and config in component design.

Here, Teacher Winer compiled a table for us, divided into four scenarios:

• Markup set —— Use tags to set
• JavaScript Set ——Use JavaScript code to set
• JavaScript Change ——Use JavaScript code to change
• User Input Change ——Changed by end user input

So let's talk about them one by one:

• Property

❌ It cannot be set by a static declarative language like markup
✅ But it can be set and changed by JavaScript
❓ In most cases, a property should not be changed by user input, but in some cases, it may come from our business logic and may be changed by user input.

• Attribute
  

❓ User input does not necessarily change it, just like Property
✅ Can be set by markup and JavaScript, and can also be changed by JavaScript

• State

❌ State is changed from within a component, not from outside it. If we want to design a component to change the state of the component from the outside, then the state inside our component will be out of control. Because we don't know when the state of our component will be changed outside the component, the consistency of our state cannot be guaranteed.
✅ But as a component designer and practitioner, we must ensure that user input can change the state of our component. For example, if a user clicks on a tab, the tab will be activated. This kind of interaction is usually controlled by state.

• Config
  

✅ Config is a one-time thing in the component, it will only be triggered when our component is constructed. So it is unchangeable. Also because of its immutability, we usually leave config to the global level. Usually each page will have a config, and then use it within the page.

Component lifecycle

When it comes to life cycles, there are two that come to mind most easily: created and destroy . All life in the world must have出生and死亡, these two life cycles.

So what is the life cycle between these two beginnings and ends? We need to think about what happens between the construction and destruction of a component.

One very important thing about a component is whether it is displayed after it is created. This involves mount in the life cycle, that is, whether the component is mounted on the "tree on the screen". We can see this life cycle in React and Vue. We often use this life cycle to perform some corresponding initialization operations after the component is mounted.

If there is mounting, there must be unmounting, so mount and unmount in the component are a set of life cycles. The entire life cycle of mounting and unmounting can happen repeatedly. We can mount it, unmount it, and then mount it again, repeating this life cycle over and over again.

So after unmount , we can return to the state of the life cycle of created component.

So when will the state of the component change? Here we have two situations:

• Programmers use code to change or set the state of this component
• User input affects the state of the component

For example, if our user clicks a button or tab, this will trigger the state change of this component. At the same time, a component life cycle is also generated, and this life cycle is Render rendering or Update updating.

All these life cycles added together are the complete life cycle of our component. The so-called willMount and didMount we see are nothing more than more detailed locations in this life cycle. Below I attach a picture of the complete life cycle.

Children

Finally, let's talk about the concept of Children. Children is the most important component feature for building a component tree, and there are actually two types of Children in use:

• Content type Children - We have several Children, but in the end, several Children can be displayed. For this type of Children, the component tree is very simple.
• Template type Children - At this time, the entire Children acts as a template. For example, we design a list , but the final result may not be consistent with what we wrote in the Children code. Because our List is definitely used for multiple list data, the number of lists represented is related to the data we pass into the component. If we have 100 actual children, our list template will be copied 100 times.

When designing the children of our component tree, we must take these two different scenarios into consideration. For example, in React, it does not have template-type children, but its children can pass functions, and then this function can return a child. At this time, it acts as a template children . So in Vue, when we make some endless scrolling lists, this has certain requirements for Vue's template children.

Conclusion

Here we have learned the concept and knowledge of the entire component. In the next article, we will design and build a component system and learn about its various practical knowledge. We will also use some typical components and typical functions to give everyone a certain understanding of the implementation of the components.

Here we supervise each other, encourage each other, and work hard together to embark on the road of learning in life and let learning change our lives!

The road to learning is boring and lonely, but I hope this can bring us more companionship and encouragement. Let’s cheer together! (๑ •̀ㅂ•́)و

This is the end of this article about the basic knowledge of front-end componentization. For more relevant front-end componentization, front-end basic knowledge, and front-end knowledge content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!