Hello, everyone, I’m Three diamonds from Tech Galaxy.

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

Speaking of front-end architecture, in fact, there are two hottest topics in front-end architecture, one is componentization, and the other is architecture pattern. The concept of componentization is a set of front-end architecture system extended from the beginning of the research on how to extend HTML tags. Its most important function is to improve the reuse of front-end code.

Architectural patterns are particularly familiar design patterns such as MVC and MVVM. This topic is mainly concerned with the interaction between the front end and the data logic layer.

Therefore, in the front-end architecture, componentization can be said to be the most important. In real engineering, componentization is often more important than architectural patterns. Because componentization directly determines the code reuse rate of a front-end team, a good componentization system can help a front-end team improve their code reuse rate, thus improving the overall efficiency of the team.

As the reuse rate increases, the amount of code that people have to rewrite becomes less efficient, resulting in less mental and emotional burden on team members.

So learning componentization can be very important

Let’s start by understanding what componentization is and the basic building blocks of a component.

Basic concepts of components

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

Componentization is both an object and a module

The characteristic of componentization is that it can be combined with tree structure and has certain configuration capability of template. This is one of the basic concepts of our component.

Differences between objects and components

First, let’s look at objects, which have three main elements:

  1. Attributes – the Properties
  2. Method the Methods
  3. Inherit relationships — Inherit

Ordinary objects in JavaScript can be described by their properties, methods, and inheritance relationships. And this inheritance, in JavaScript, is done using prototype inheritance.

When I say “normal objects,” I don’t mean complex function objects or other special objects. In JavaScript, properties and methods are one and the same.

Compared with components, components contain richer semantic elements. Components include:

  • Attributes – the Properties
  • Method the Methods
  • Inheritance, Inherit
  • Feature – the Attribute
  • Configuration and State — Config & State
  • Event – the Event
  • Lifecycle — Lifecycle
  • Child component — Children

“Properties” and “Attribute” are very different in English, but are often translated as “attributes”. If both words appear, Attribute is translated into “Properties” and Properties is translated into “Properties.” How can these two elements be distinguished? Here will be detailed with you at the end of the article.

Next comes the component Config, which is a configuration of the component. We often use Config when creating an object in a constructor. The constructor argument we pass is called “Config”.

The component also has state. A state changes when the user performs an operation or when some method is called. This is the state of the component, and it can change with some behavior. State and Properties, Attributes, and Config can all be familiar or identical.

An event is the awareness of an “event,” and an event is passed out by a component. Our component is mainly used to describe things like the UI, and basically it will have this kind of event to implement some type of interaction.

Each component has a lifecycle, which will be studied in more detail later in this article.

Children is a very important part of the component, and children is also a necessary condition of the component, because without children the component cannot form a tree structure, so the ability to describe the interface will be much worse.

There were some popular drag and drop systems where we could drag written UI components onto a page to create our system interface. However, in addition to being able to drag and drop in certain areas, we also need some automatic sorting, component nested component functional requirements. At this point, it doesn’t work without a tree structure between components.

In the end, components add a lot of semantically relevant concepts to objects, which makes them a very suitable concept for describing UI.

Component Component

Let’s use a diagram to take a closer look at the components.

The most direct source of component change is user input and actions. For example, when a user selects an option in our checkbox component, our state and even our children component will change.

The cases on the right are the relationships between the component’s developer and component. One is when the developer uses the component’s Markup Code to influence the component. Attribute is used to change the attributes of a component.

Attribute is a declarative language and Markup Code. Markup Code doesn’t have to be the language of our HTML XML class. In the vast ecosystem of markup languages, there are many languages that can be used to describe the structure of an interface. But the most popular ones are based on XML. The most common in our Web world is XML. JSX can also be understood as an XML structure embedded in a programming language.

Developers can influence components with properties as well as attributes. The component itself has properties, and when a developer modifies a component’s properties, the component changes. And this is the same concept as Property in objects.

Are attributes and properties the same? Sometimes it is, and sometimes it is not, entirely up to the designer of the component architecture. The implementer or designer of a component can unify attributes and properties. It is even possible to unify state, config, attribute, and property.

Then there is the method, which is used to describe a complex process, but in JavaScript Property is allowed to have methods like GET and set, so in the end method and Property are almost the same.

So here we can establish the concept that developers using components will use methods and properties, the elements of the component. But if a developer developing a component needs to send a message to a programmer using the component, the event is needed. The component sends an event message to the consumer when a change is triggered internally by an action or event. So the direction of the event here is the other way around, propagating from the component.

From this diagram, we can clearly understand the role of each component’s elements and the direction of their information flow.

Characteristics of the Attribute

Of all the components, attributes and properties are the most complex.

From the understanding of the English word Attribute, it is more descriptive. For example, if we describe a person with a lot of hair, a handsome face and white skin, these are attributes, which can also be used to describe the characteristics and features of an object.

Property is more of a subordinate relationship. For example, we often find an object in development that has a Property of another object, so there is a probability that there is a dependency relationship between them, and the child object is subordinate to the parent object. But there’s a special case where if we have weak references, one object refers to another object, and that’s a completely different concept.

That’s the difference between these two words in English, but they are also different in practical situations.

Property is often used in our object-oriented world because it is dependent. Attributes were originally used in our XML. Sometimes they’re the same, sometimes they’re different.

The Property Attribute contrast

Let’s use some examples here to see the difference between attributes and properties. 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>
Copy the code
  • Attributes in HTML can be set using HTML attributes
  • It can also be set through JavaScript

Property:

myComponent.a = 'value';
Copy the code
  • So this is what defines an element a = value
  • This is not an attribute, this is a property

A lot of students think that these are just two different ways of writing, but they actually behave differently.

The Class attribute

<div class="class1 class2"></div>

<script>
  var div = document.getElementByTagName('div');
  div.className Class1 class2 Is the output
</script>
Copy the code

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

In order for this keyword to be used in this way, the HTML has made a compromise design. In HTML the property is still called class but in the DOM object the property becomes className. But there is also a reflective relationship between the two, and this magical relationship can often get people into a bit of a pickle.

For example, in React, we say className and it automatically sets the Class.

Style property

There is no inconsistency between class and className in JavaScript today. We could have written div. Class. However, the class name is not supported in HTML, which is a problem due to some historical baggage.

Sometimes an Attribute is a string, and in Property it is an object that has been semantically translated into a string. The most typical is Style.

<div class="class1 class2" style="color:blue"></div>

<script>
  var div = document.getElementByTagName('div');
  div.style // This is an object
</script>
Copy the code

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 a vaule structure.

The Href attribute

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

For example, the href value is “//m.taobao.com”. In this case, the HTTP or HTTPS protocol is based on the current page, so the href must be compiled to respond to the current page protocol.

Those of you who have done HTTP to HTTPS transformation know that when making our website use HTTPS, we need to change all the dead HTTP or HTTPS urls to use //.

So whatever we write in href comes out, that’s the attribute. Resolve is our property if it passes through resolve.

<a href="//m.taobao.com"></a>
<script>
  var a = document.getElementByTagName('a');
  // the result is "http://m.taobao.com", and the url is resolved
  // So this is a Property
  a.href;
  // this gets "//m.taobao.com", which is exactly the same as the HTML code
  So this is an Attribute
  a.getAttribute('href');
</script>
Copy the code

We can also see in the above code that we can access both property and attribute. Their semantics are very similar, but they are not the same thing.

But if we change either side, we change the other side. This is the phenomenon we need to pay attention to.

The Input and the value

This is the most amazing pair, and Value is a special pit.

Many of us assume that the values in property and attribute are exactly equivalent. No, the input value in this attribute is equivalent to the default value of a value. The attribute of the input does not change whether the user enters a value in the input or whether the developer uses JavaScript to assign a value to the input value.

Property is shown first in the input display, so the value in the attribute is just a default value. This is a very famous pit. If you have used JQuery in the early days, we will think that the prop inside is the same as attR.

So the JQuery library has a method called val, so we don’t have to think about the attribute or the value of the property, we can just use the val that it provides.

Here we are working together to enhance HTML properties and attributes. The other aspect is to recognize that even a tag system designed by a very top computer scientist has two similar attributes that are not equivalent. So if we were to design a tag system, would we make properties and attributes equivalent or not? Let’s answer this question together after we’ve learned all about componentization.

How to design component state

Let’s look at the differences between property, Attribute, state, and config in component design.

Here, Teacher Winer sorted out a table for us, which was divided into four scenes:

  • Markup set — Sets with tags
  • JavaScript Set — Uses JavaScript code to Set
  • JavaScript Change — Use JavaScript code to make changes
  • User Input Change – The end User’s Input changes
Markup set JavaScript set JavaSscript Change User Input Change
❌ ✅ ✅ ❓ property
✅ ✅ ✅ ❓ attribute
❌ ❌ ❌ ✅ state
❌ ✅ ❌ ❌ config

So let’s talk about it one by one:

  • Property
    • ❌ it cannot be set by the markup static declaration language
    • ✅ but it can be set and changed by JavaScript
    • ❓ In most cases, property should not be changed by user input, but in a small number of cases, it may be from our business logic, so it is possible to accept the change of user input
  • Attribute
    • ❓ user input does not necessarily change it, as with Property
    • ✅ can be set by markup, JavaScript, and can also be changed by JavaScript
  • State
    • The ❌ state can be changed internally, not externally. If we want to design a component to change the state of the component from the outside, our internal state of the component is out of control. Because we do not know when the external component will change the state of our component, the consistency of our state is not guaranteed.
    • ✅ But as a component designer and practitioner, we must ensure that user input can change the state of our component. For example, when a user clicks a TAB, the TAB is activated. This interaction is usually controlled by state.
  • Config
    • ✅ Config is a one-time thing in a component that only fires when our component is constructed. So it’s immutable. Also because of its non-modifiability, we usually leave config to the global. Usually each page will have a copy of config, which is then used within the page.

Component Lifecycle

When it comes to life cycles, the two things that come to mind are created and destroy. The life of all things in the world must have two life cycles of birth and death.

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

One of the most important things about a component is whether it is displayed after it is created. This is where the mount in the lifecycle is concerned, that is, whether the component is mounted to the “tree of the screen.” This lifecycle can be seen in React and Vue, and is often used to initialize components after they have been mounted.

There is mount and there is unmount, so mount and unmount in a component are a set of life cycles. And this whole life cycle of loading and unloading can happen over and over again, we can hook it up, we can unload it, we can hook it up again, we can go through this life cycle over and over again.

So after unmount, we can return to the state of the created build component lifecycle.

When else does a component change its state? Here we have two cases:

  • The programmer uses code to change or set the state of the component
  • The state of the component was affected by user input

For example, when the user clicks a button or Tab, the component’s state changes. There is also a component lifecycle, which is the Render or Update lifecycle.

All of these lifecycles add up to the complete life cycle of our component. What we see as willMount, didMount is nothing more than a more detailed location in this lifecycle. Let me give you a picture of the full life cycle.

Children

Finally, let’s talk about the concept of Children. Children are the most important component feature to build a component tree, and there are actually two types of Children in use:

  • Content Children — We have several Children, but how many Children will be displayed in the end. For this type of Children, the component tree is very simple.
  • The Template type ChildrenAt this point the whole Children act as a template. Let’s say we design alistBut the final result is not necessarily the same as what we wrote in the Children code. Since our List must be used for multiple List data, the number of representations of the List is related to the data data we pass into the component. If we had 100 actual children, our list template would be copied 100 times.

It is important to keep these two different scenarios in mind when designing the children of our component tree. For example, in React, it doesn’t have a template children, but its children can pass a function that returns a child. At this point it acts as a template for children. So in Vue, when we do endless scrolling lists, this has certain requirements for the Vue template children.

conclusion

Here we have learned the concept and knowledge of the whole component, the next article we will design and build a component system together, and understand its various aspects of practical knowledge. We will also use some typical components and typical functions to give you a sense of the implementation of components.

Bloggers are learning live at station B. Welcome to live Studio.

We are here to supervise each other, encourage each other, and strive to embark on the road of learning in life, so that learning changes our life!

It is boring and lonely on the way to study, but I hope it can bring us more company and more encouragement. Let’s refuel together! (๑ • ̀ ㅂ ́) organisation

I am SAN Zuo from the wechat public account technology Galaxy, a technologist who is reshaping knowledge. See you next time.