Development of Front-End component

Component, Chinese is called a component, or component. Use is very broad, its core meaning is reuse, relative module, for dependence has higher requirements.
module, in Chinese as a modular or modules. Its core meaning is the separation of responsibility, which belongs to the modular output of the code level. It is itself a function of providing services logic, is a group of certain cohesive Code combination, the responsibility is clear.
Components (Component) and modules (module) are a pair of confusing nouns and are often used to replace each other. Personal summary, from the design point of view, components emphasize reuse, modules emphasize responsibility (cohesion, separation), or component is to achieve the requirements of reusable modules (remember the interview, the interviewer has mistaken these two concepts.) ）。
Components in front-end Web applications refer to software that is designed to be generic and used to build larger applications that have many forms of representation. It can be either a UI (user interface) or a pure logical code as a "service." The UI component is easier to understand because of the visual representation. Simple examples of UI components include buttons, input boxes, and text fields. Whether it's a hamburger-shaped menu button (whether you like it or not), a tab, a calendar, a menu of options, or WYSIWYG rich-text editor is a more advanced example. The types of components that provide service types can be difficult to understand, including Cross-browser Ajax support, logging, or the ability to provide some sort of data persistence.
Based on component development, the most important thing is that components can be used to form other components, while rich-text editors are a good example. It is made up of buttons, drop-down menus, and some visual components. Another example is the video element on the HTML5. It also contains a button and contains an element that can render content from a video data stream. why to build components. High Cohesion

We organize some of the related functions together, encapsulate everything, and in the case of the component, it may be related to functional logic and static resources: JavaScript, HTML, CSS, and images. This is what we call cohesion. This approach makes the components easier to maintain and, after doing so, increases the reliability of the components. At the same time, it can make the components of the function clear, increase the possibility of component reuse. Reusable

The sample components you see, especially the Web Component, are more concerned with reusable issues. Features are clear, the implementation is clear, and the API is easy to understand. It is natural to facilitate component reuse. By building reusable components, we not only maintain the DRY (do not repeat wheel-making) principle, but also have the corresponding benefits.
Here's a reminder: Don't try to build reusable components too much. You should focus more on the specific parts of the application that you need. If the corresponding requirement arises later, or if the component is indeed reusable, take a little extra time to reuse the component. In fact, developers like to create reusable blocks of functionality (libraries, components, modules, plug-ins, etc.) that are too early to make you miserable. So, learn the other benefits of component-based development and accept that not all components can be reused. can be interchangeable

An API that features a well-defined component makes it easy for people to change their internal functionality implementations. If the component inside the program is loosely coupled, it can actually easily replace another component with one component, as long as the same api/interface/convention is followed. can be combined

component-based architectures make it easier for component groups to synthesize new components. Such a design makes the component more focused and makes it easier to build and expose features in other components. Whether it's adding functionality to a program, or creating a complete program, more complex features can be used to do the same. This is the main benefit of this approach. Modular Development

As shown above, a simple interpretation: each independent visual/interactive region on the page is considered a component, each component corresponds to an engineering directory, and the various resources required by the component are maintained near this directory; Because components are independent, components and components can be free combination; A page is simply a container of components, responsible for composing components to form a fully functional interface; You can delete/replace the entire directory when you do not need a component, or if you want to replace the component.

The second description of the nearest maintenance principle, I think the most engineering value of the place, it provides a good strategy for front-end development, each developer will clearly know that their own development and maintenance of functional units, the code must exist in the corresponding component directory, In that directory can find all the internal logic of this functional unit, style or JS, page structure is all right there.
Based on this engineering concept, it is easy to divide the system into separate components for the division:

Because the system function is divided into the independent component, the granularity is more fine, the organization form is loose, the developer will not produce the development time sequence dependence, greatly promotes the parallel development efficiency, also is easier to support many teams to maintain a large-scale site development.

The entire front-end project can be divided into such several development concepts:
-JS module: Independent algorithm and data unit, browser environment detection (detect), network request (AJAX), application Configuration (config), Dom operation (DOM), tool function (Utils), and JS unit in component;
-CSS Modules: Standalone functional style units, raster systems (grid), font icons (icon-fonts), animated styles (animate), and CSS units in components;
-UI components: Standalone visual/interactive functional unit, header (header), footer (footer), navigation bar (NAV), search box (searching);
-page: Front end this GUI software interface state, is the UI component's container homepage (index), the list page (lists), the user manages (users);
-Application: The entire project or the entire site is called an application, consisting of multiple pages.

Based on these ideas, front-end development has become this way:

。 The entire Web application is made up of pages

Combined with the above description, for the general small and medium sized projects, can be roughly planning such a source directory structure:

reusability of Front-End components

In the so-called component, the core meaning is to extract the real reuse of the value of things. What kind of things have the value of reuse?

The reusability of public styles is also relatively easy to recognize, so there will be a bootstrap,foundation,semantic of these things, but they are also not a pure style library, but also with some small logical encapsulation. Business logic this piece of reuse is a lot of controversy, on the one hand, many people do not agree that the business logic also needs to be modular, on the other hand, this piece of material how to component, also very need to think. In addition to these, there is a large number of business interface, this piece is obviously very low reuse value, there is no reusability, but there are still many solutions to "component", making them become "not reusable components."
The essential purpose of a component is not necessarily to be reusable, but to promote maintainability.

For a certain scale of web applications, all things are "modular", the management will have greater convenience. I would like to cite an example, also write code, the short code is obviously more readable than the long code, so many languages will suggest "a method generally do not exceed the number of lines, a class is best not more than the number of lines" and so on.
This time we look at the HTML part, if you do not consider the use of technology such as templates, some of the interface of the light layout code to write a lot of, like some forms, need to set a layer, many simple form elements need to set a three-level, not to mention some complex layout of things. In particular, the entire system after the single page, the interface of the Header,footer, a variety of nav or aside, it is likely that there is a certain complexity. If the code for these things is not split, then the HTML of the main interface must be rather ugly.
From this point of view, the pieces are like components, but if you look at it from a reusability standpoint, it's possible that most things, each one of them, have a single place with no reusability at all. This is simply to make the whole project easy to manage and easy to maintain.

This is where we focus on how different frames/libraries are being processed by the UI layer, and there are two types, templates, and functions.
A template is a very common thing, it uses an HTML string to express the original structure of the interface, and then generate a real interface by substituting the data, either to generate the target HTML, or to generate automatic bindings for various events. The former is a static template, and the latter is a dynamic template.
Other frameworks/libraries prefer to use function logic to generate the interface, the early ExtJS, now react (it is still possible to use the template, but also provide external component to create the interface of further encapsulation--JSX), etc., the advantage of this technology is different platform programming experience consistent, You can even encapsulate the same components for each platform, and callers easily write a piece of code that is available on the web and on different native platforms. But this kind of way also has the more troublesome place, that is the interface adjustment is more cumbersome.

There is a simple scenario: An employee list interface consists of two parts, an employee form, and a form for filling out employee information. In this scenario, what components exist.

For this problem, there are two main tendencies, one is to simply encapsulate "control" and more versatile things into components, the other is the whole application is modular. For the previous method, there was only one component of the data table. In the latter way, this might be possible: data tables, employee forms, and even a larger component of the Employee list interface. These two ways are the "local component", "full component", as we have said before.

As we mentioned earlier, full-component management is an advantage, it can be different levels of things to make a similar structure, such as the business scene just now, it is likely to end up writing this way:

<Employee-Panel>
<Employee-List></Employee-List>
<Employee-Form></Employee-Form>
</Employee-Panel>

These are the main issues of full tagging:
First, semantics cost too much. As long as you use a label, you must give it the appropriate semantics, that is, naming. But the actual use of the time, it is likely just to simplify a bunch of HTML, in the end the simplification of that thing should be called what name, just name also cost unknown how many brain cells. Second, the configuration is too complex. There are many things that are not suitable for encapsulation, not only the cost of encapsulation, but also the cost of the use will be large. It is sometimes found that most of the calling code is written in various configurations.

After the discussion, let's look at another question: If the UI component has business logic, what should be done about it.

For example, the Sex-selected dropdown box, which is a very versatile feature, is supposedly a good fit to be provided as a component. But we are a bit puzzled as to how to encapsulate it. In addition to the interface and data in this component, should this data be built into the component? Theoretically, from the encapsulation of the component, it should all be inside, and thus a component is created:

<GenderSelect></GenderSelect>

The gender data is naturally placed inside the implementation of the component, in a dead-write array. This is too easy, let's change it, and change it into a national drop-down box for merchandise sales. But we have a requirement that the information of the country where the goods are sold is uniformly configured, that is, this data comes from the service side. At this point, do you want to encapsulate an HTTP request into this component.

It is not possible to do so, but there are at least two questions:

If such a component occurs more than once in the same interface, there may be a waste of the request, because a component instance produces a request. If the configuration interface of the national information exists simultaneously with this component, when we add a country to the configuration interface, the data in the Drop-down box component is not refreshed in real time. The first problem is the waste of resources, the second is the inconsistency of data. Once in many systems, everyone is manually refreshing the current page to solve this problem, but in this era, people are the pursuit of experience, in a fully modular solution, should not have such problems.
How to solve such a problem. That is to introduce the concept of a layer store, each component does not go directly to the server to request data, but to the corresponding front-end data cache to get the data, so that the cache itself to the server to maintain synchronization. Therefore, in the actual process of the program, whether it is based on Angular,react,polymer, and finally must have made a store, or there will be many problems.