Laughing and chatting Modular

In today's front-end development domain, Rounds's component development, such as booming, is also the voluminous of the article on component discussions in the front-end technology circle. However, other people's understanding is ultimately someone else's, as a chest of small blog developers, I would like to be able to based on their own understanding and practical work, summed up their knowledge of component and component development.

When I first approached the concept of component, I was in a daze, such as falling deep in the clouds. What is a component? What is component development? Why does Daniel know so much and I don't know? This should not be my personal question, and every novice who has the concept of this contact will be puzzled.

Why does Daniel know so much and I don't know?

I used to worry about a similar problem countless times, and I felt impatient. To answer this question, we need to have a basic understanding that any new concept is inherited and developed in the practice and summary of countless predecessors. The development of components is no exception. This problem involves cognition, which can lead to many problems worth exploring, but this is not the focus of this article. On the development of the front-end component, I recommend the Xufei of the Great God: the component of Web application (a)-the basic idea.

　　

What is component development?

The original architectural design is more concerned with the horizontal hierarchy, namely the data layer, the logical layer and the UI layer. The modular architecture must also focus on vertical isolation and decoupling. After layering and sub-modules, each business component consists of a three layer of the respective deployment package, which is itself a combination of technical components and service components. By the data layer, the logic layer, the interface layer three layer three business packages can constitute a complete independent function of the business components. "People's Month Myth blog"

This explanation is correct, but too conceptual, and I understand that the component development is to divide complex and confusing page logic into separate business units .

　　

What is a component?

According to the above answer, we can basically determine that the component is a separate logical unit in the page. This conclusion is universal, but every high-up theory will be landed, according to the specific circumstances of the specific answer. Components to the front end there is a response to the front-end technology: The front-end component is a template, style, code logic, a separate, reusable business logic unit, where the template is assumed by HTML, style is responsible for CSS, code logic written by JavaScript.

This map of the Zhang Yunlong, which shows the basic intent of the component and the basic composition of the component.

　　Any kind of new development way, can not rely on reading only a few articles to understand, must be practical and in the work to summarize, in order to thoroughly grasp. So I do not expect to rely on a few paragraphs above to let the reader fully understand the component and component development.

Next, I will share with you my knowledge and experience of the components based on my actual development experience.

　　

　　Basic culture of components

Any gorgeous idea has a set of plain code implementations. Above, we talk about the concept of component from the level of abstraction, put it into the actual code world, how to realize it? As we all know, JavaScript is an object-oriented language, and the most important feature of object-oriented language is abstraction. Put in the actual development is to define a base class, application of our present scene, we need a component base class-Component. This base class provides the basic functionality of the component. What should be the basic function of the concrete? Don't worry, this problem should be put on first.

　　Management of components

Looking at the diagram above, we will find that the entire page is made up of different functional business components. This leads to another problem, when the component of a page is very long, we need a unified management of the warehouse-crepository. Each component is to register its own ID to the warehouse, the warehouse provides management functions, such as add and delete changes. Specific methods vary by application, but several common methods can be consulted:

Count:number. // number of components in the entire app  function// Add a component to the warehouse  function//  Remove  a component from the warehouse function// find components from the warehouse by ID

Once we know the warehouse, we can put our main energies back on the component.

　　The life cycle of a component

The concept of life cycle first in the software engineering contact, unfortunately I do not have any interest in those boring theory, on the lesson to foggy, has been back to the professor. Let me give you an example of what everyone has to experience. Components such as human beings, human life has an end, the components of life must have. Dividing the life cycle of a component into different stages to deal with different logic is like having to face different problems at different stages of a person's life.

Constructorfunction(){}//constructors, handling external parametersmixinproperties:function(){}//at this stage, mix the necessary attributesparsetemplate:function(){}//parse the template at this stage, transforming the template from a string into a DOM nodePostCreate:function(){}//at this stage, the template parsing is complete and you can access the root node of the component Croot. You can now access or bind events to the DOM tree of the component. However, the component is not added to the page Dom tree at this time. Startup:function(){}//at this point the component is added to the DOM tree, where you can do some initialization work after the component joins the page DOM. For nested components, you need to handle the startup of the subassemblyDestroy:function(){}//Component Life End, enter the destruction phase, log out from the component repository

There must be distortion in the metaphor, the life of the component is certainly not comparable to that of man, but I find that the life cycle above is very similar to the baby's process of being pregnant and being born.

Constructorfunction(){}//fertilized egg Statemixinproperties:function(){}//chromosome recombinationparsetemplate:function(){}//the growth and development of infants within the motherPostCreate:function(){}//babies grow and develop within the mother, and mothers are about to be born.Startup:function(){}//the baby was born and recognized by societyDestroy:function(){}//individual extinction, abolition of social registration and so on

　　

　　Component's property accessor

Access to the internal data of the component should provide a unified access channel to the outside, usually this part is the property's accessors and evaluators (get and set).

Set (prop, value)// Assign a value to a property of a component get (prop)// to get a property value from a component

To be clear, the set and get are not only the same as the point syntax of the simple assignment and value, otherwise it is superfluous. The brother who used C # knows that there are "get and set of attributes" in C #, which avoids direct access to the field, where the get and set of the component should have the same functionality, and the specific implementation is to follow the article.

　　Template parsing for components

Encountering a template typically encounters a requirement for data binding, possibly a two-way binding or a one-way binding. Two-way bindings, such as numerous MVVM frameworks, may read component data to render DOM elements during template parsing, or the changes to DOM elements can be applied to the component's internal data after the component Dom tree has been generated. One-way bindings often appear in the MVC framework, such as dojo, that simply binds the DOM element to a property inside the component, or binds the interaction event to the component's internal method.

There is no annotation feature in JavaScript, so many binding features add custom attributes to the template and process custom attributes during parsing.

When it comes to the binding of events, the memory leaks caused by events cannot be overlooked. This is when the component is destroyed, and the events that are bound inside the component are processed together. Includes events that are bound in the template and that are manually bound inside the component.

　　Component relationships

When a page becomes more and more complex, there is bound to be nesting between components. Nesting implies a parent-child relationship, sibling relationships, and so on. Nested management can refer to the hierarchical relationships in the DOM and provide the appropriate processing methods. But generally speaking, only need to manage the father-child relationship, the management of the Brotherhood is often too complex, and usually, a getchildren, and then according to the index to meet the requirements. Therefore, the management of component relationships in most class libraries requires only two methods:

GetParent:function() {}// Gets the parent component of the component getChildren:function() {}//  get all subcomponents inside a component

Component Communication

As components become more complex, the question of how to communicate between the components should be put on the agenda. JavaScript itself is suitable for message-driven, the processing of communication between components of course, the use of materials, the event mechanism is the best solution, so the front-end components should be on the basis of event mechanisms (often semantic events) to provide communication capabilities. Components should either receive events or send events, and should provide methods separately:

On:function// for Binding component event emit:function// component Outgoing event

Destruction of components

Component destruction is part of the component life cycle, and when component functionality becomes complex, the correct and reasonable destruction of components becomes particularly important. The destruction of components usually takes into account the following aspects:

• Unbind internal events within a component
• Destruction of component Dom
• Destruction of components ' internal properties
• Sub-component destruction
• Component logoff

　　Parsing of components

If all the components are to be initialized manually through new class, this is understandable, but in today's era of tagged language prevalence, whether there is a more convenient way to develop, the custom components can be written in a tabbed way. The answer is yes, the mainstream class library generally has two approaches: one is a completely custom label, such as Angular2; one is to customize label characteristics, such as dojo. All of this requires the ability of the base library to provide component parsing.

The general idea is to scan the entire DOM tree, parse custom tags, custom attributes, and instantiate them as custom components in a depth-first search. Interestingly, because of the presence of component nesting relationships, custom components, like the DOM tree, are also an inverted tree structure.

Thank you for reading this, some brothers may say, this article talk about a lot of components, components of development, but are theoretical things. Well listen to the call methodology, said it is not good to listen to the nonsense. If you don't come up with something real, it's Xuyuweishe of the gas overflow in the intersecting of the table, flutter people forehead. Then follow the next few articles, I will work with you according to the theory of this article, step by step to achieve a set of basic components Class library.

Reference article:

Component of Web application (i)--basic idea

Component of Web application (II.)--control platform

2015 The path of the front-end component framework

What are the modularity and component definitions of front-end development, and the relationship between them?

Rethinking of the component-structured architecture

Laughing and chatting Modular