The idea of front-end component

1. Opening

First of all, why write this article: I do not know when to start, we believe that the front of Moore's Law: "Every 18 months, the front-end difficulty will be increased by one times." I do not fully endorse the reliability of this number, but I am quite certain of the meaning of this statement.

Yes, the front end is getting simpler, but it's getting more and more complicated-simple enough that you can build a framework with a GitHub starter, integrate all the family buckets, cover unit tests and functional testing, including deployment and release, and even the UI libraries you use to create a few lines of CSS Can be complex enough to have so many frameworks and libraries emerging, you have not had time to learn the official website of the doc, there has been a new alternative, that is not to mention the quiet heart to learn the source code or the principle of scrutiny, not follow the footsteps of forced to move bricks naturally slightly tired.

It is the front end of the rapid development so that the front looks simple, but if you want to go deep but it is not easy. Incidentally, at the end of June last year, ES8 has released, yes, you did not read the wrong, is not feeling to learn not to move (joking, actually also did not update what, there will be no more es5->es6 this span).

Therefore, I recently felt that the use of the framework is a little more, have to calm down to precipitate precipitation-why do you want to say the idea of the component. Because I think it is accompanied by the front-end development of an indispensable design idea, the current several popular frameworks are also very good to achieve the component, such as React,vue. React used to be more than before, so this article I decided to Vue as the basis, to talk about the front-end module, modular, maintainable design fine thinking. 2. What is Component

Component is not unique to the front-end, some other language or desktop programs, and so on, have a modular precedent. To be sure, as long as there is a UI layer on display, there must be a place to be modular. In simple terms, a component is to see a piece of UI style and its corresponding function as a separate whole, regardless of where the whole is used, it has the same function and style, so as to achieve reuse, this holistic thinking is the component. It is not difficult to see that the component design is to increase the reusability, flexibility, improve the system design, so as to improve the efficiency of development. 3. Evolution of the modular

If your understanding of JS is still in jquery (jquery itself is a very good library), skip this article (a joke). At that time, most front-end development should be very procedural development: Operation DOM, launch Ajax request, refresh data, local update page. This kind of movement repeatedly, even in the same project the same process may have to repeat, in fact, jquery itself has its own modular design, and sometimes we will use a similar jquery UI and other good libraries to reduce the workload, but please note that here I think it is modular.

Frequently manipulating the DOM, the process-style development approach is really not good. At this time began to popular mv*, such as MVC, the front-end began to learn the idea of the back end, talk about business logic, UI, functions, can be divided according to different documents, structure clear, design clear, development is also good. On this basis, there is a more good MVVM framework, it simplifies the front-end operation and gives the front-end UI a real meaning: Any UI you see should correspond to its corresponding ViewModel, that is, the view you see is the real data, and it implements the two-way binding, As soon as the UI changes, the data corresponding to the UI changes, and vice versa. This is really handy, but most of the MVVM frameworks are not component-based, or not well implemented, because the biggest problem with MVVM is:

1. Efficiency, as long as the data changes, it is the following monitoring data binding UI will generally be updated, inefficient, if you operate frequently, it is likely to be adjusted hundreds of thousands of times (it is possible to level too deep or monitor too much data changes).

2. Because MVVM generally require a rigorous viewmodel scope, most cases do not support multiple bindings, or only a single root node is allowed to be a top-level DOM render, which makes it difficult for the component (to bind partially the UI separately).

Then, on this basis, some of the new front-end framework "to take its essence, to its dross", began to vigorously promote the front-end component development, from this point, react and Vue are similar.

But from the framework itself, react and Vue are completely different, the former is a one-way data flow management design pioneer, if I do not make an inappropriate comparison, I think React+redux is to the extreme of MVC (Action->request, reducer- >controller) While the latter is an up-and-comer, not only absorbs the react data stream management way (Vue itself can also use similar react way to develop, but the difficulty is bigger, not very vue) design idea, Also implemented MVVM two-way binding and data monitoring (this should be the core of the Vue), so Vue is more flexible, you can expand on demand, it will dare to call itself an incremental framework.

PS1: It's not about what's good or bad, but I like the two frameworks because they're all very well implemented.

PS2: The above mentioned modularity, personally feel that if more broadly speaking, modularity and component are not in a dimension, and modularity is often the design of code and the design of the project structure, but many times in the narrow sense of the scene, such as a very common function, can be fully modular or modularized, The two are very similar at this time, the biggest difference is that the components must be modular, and often need to instantiate, and should be endowed with life cycle, and modularity is often a direct reference. 4. How to implement the component

I take SouFun as an example (recent high prices, the big guys are still blowing a variety of cattle X said prices will soon after the price of cabbage, I by the way mark see after the face) for demo analysis. Screenshots are as follows:

4.1 Analyzing page layouts

In general, it can be divided into top search, intermediate content display. The middle content is divided into three types of part1,2,3. Due to the problem of space, this article only analyzes part1,2,3

Each part can also be divided into header (title + link) and content (each parts is not the same)

4.2 Preliminary development

If there is no design, the following code may appear:

<template> <div id= "app" > <div class= "nav-search" >...</div> <div class= "Panel" > <div class= "Part1 Left" > <div> <span> Vanke City Run Garden property dynamic </span> <a href=
      > more news >></a> </div> <div> Here is the specific content of each part </div> </div> <div class= "Part2 right" > <div> <span> Real Estate story </span> <a href= "" > More >></a> </div> <div> Here is the specific content of each part </div> </div> <div C 
          lass= "Part3" > <div> <span> Vanke City run garden type </span> <a href= "" > Two habitat (1) </a> <a href= "" > Three (4) </a> <a href= "" > Four Habitat (3) </a> <a href= "" > More &GT;&G T;</a> </div> <div> Here is the specific contents of each part </div> </div> </div> &L T;/div> </template>

 

which I omitted most of the details of implementation, the actual amount of code should be here several times.

This code has several questions:

The structure of the 1.part1,2,3 is very similar, some Xu repeat

2. The actual amount of code will be many, it is difficult to quickly locate the problem, maintenance of more difficult 4.3 to simplify

The first thing we can do is separate the part1,2,3 so that we have three separate files, so the structure will be very clear.

<template>
  <div id= "app" >
    <div class= "Nav-search" >...</div>
    <div class= " Panel ">
      <part1/>
      <part2/>
      <part3/> 
  </div>
</template>

This is similar to the process of gradually splitting a large function into several parts, and it is not difficult to imagine that the code in part1,2,3 is inherently poorly applied, and that it is only here that it can be referenced. (But I have seen a lot of project code, is so dry, think that they do the component, abstraction is not bad (@_@)) 4.4 Component Abstraction

Looking closely at part1,2,3, as I said above, they are very similar: all have the same outer border with shadow, all with the head up and display more, the contents of their content is not detailed, these three are exactly the same.

In this way, we will have a highly similar business data extraction, implementation of component abstraction.

Part.vue

<template>
  <div class= "part" >
    <div class= "Hearder" >
      <span>{{title}}</span >
      <a:href= "linkformore" >{{ShowMore | | ' More >> '}}</a>
    </div>
    <slot name= ' content '/>
  </div>
</template >

We have made props of the data that can be abstracted in part, including using slot to do the template, and ShowMore | | ' More >> ' also takes into account the Part1 link name and several other part inconsistencies.

This makes App.vue clearer.

<template>
  <div id= "app" >
    <div class= "Nav-search" >...</div>
    <div class= " Panel ">
      <part
        title=" Vanke City Run Garden property dynamic "
        linkformore=" #1 "
        showmore=" more dynamic >> "
      >
        <div slot= "Content" > here is the specific contents of Part1 </div>
      </part>
      <part
        title= "real Estate Story"
        Linkformore= "#2"
      >
        <div slot= "Content" > here is the specific content of Part2 </div>
      </part>
      <part
        title= "Vanke City Run Garden type"
        linkformore= "#3"
      >
        <div slot= "Content" > This is the specific contents of PART3. </div>
      </part>
  </div>
</template>

Here are a few things to explain: 1. Three part of the UI differences should be defined where.

For example, three part widths are different, and part1 and part2 may need to be floated.

It must be remembered that this difference is not the component itself, the <part/> design itself should be without floating and width of 100%, as for who 100%, it depends on who cited it, to the left or to the right to float, It also depends on the container that references it, and in the code above, App.vue is supposed to be <part/> Container,app wants a part (part1) with a left float and a width of 80%. A part (part2) with a width of 20%, with a right float and a width of 100%, but all of them are a, so the app should set these differences.

Keeping this in mind will give you an abstraction and an extension but with a multiplier effect. 2. The data differences in the three part should be defined where.

In Part3, for example, the other part has only one more >> link, but it has multiple (one, two ...).

Here I recommend that this difference be reflected within the component, and there are many ways to design it:

For example, the link array can be converted into links;

For example, you can view more >> as a default link, and the extra part is a user-defined special link, which is combined to form links. User-defined defaults are not, and they need to be passed in when referencing components.

In short, as long as there is data differentiation, it should be combined with the component itself and the business context will be reasonable to eliminate the difference within. 3. Note how the data in the component is named

A general, scalable component, must have a very reasonable name, such as the observation of the name of some components library, there will always be similar list,data,content,name,key,callback,classname and other nouns, Will never appear in our system, such as Iterationlist, ProjectName and other business terms, these nouns and any product and application, it is related to its own abstract components, only to indicate the internal data meaning of the component, and occasionally will represent its structure, so only in this way, so that users can be generic.

We also need to follow this design principle when it comes to components, but libraries tend to be generic to developers, and we can reduce scope to be universal in the entire app. So from this perspective, good assembly must have good BA and UX, which is Truth 5. Written in the last

You might think that this abstraction is not too much of a necessity, after all, it is a static UI (pure component), but any design is derived from a certain degree of complexity, in fact, in most cases, this design is the need to incorporate functional logic code, And not just the UI (such as ANTD, Element-ui, etc.), the example I have here is relatively simple and does not want to have too much code.

Personally think that in a large front-end project, this component of abstract design is important, not only increased reusability increased productivity, but also to some extent reflects the programmer's understanding of business and product design, once there is a problem or need to expand the function, you will find out how the previous design is made Sense (after all, demand is always changing).