Element – the UI is a useful a UI framework based on vue, the result of such UI framework and components, make our front-end developer can bring the box in the process of work, reducing the rolling time, (mainly is to reduce the overtime hours), but on this basis, some friends in order to further reduce work overtime of time, often can choose, Based on the UI framework, encapsulate some custom components, including some common Settings, methods, so as to reduce the amount of code and repeated copy and paste operations. With this in mind, this article looks at some of the techniques you can use when encapsulating custom components based on Element-UI.
Combing logic
When we want to do something new, we start with the basic “what”, “how” and “how” questions, and packaging components is no exception.
1. What do you do
Personally, when we want to go to encapsulate a new component, especially on the wheels of the existing optimized packaging, it must want to abandon or optimize some tedious operation, or the basis of the original component function can’t meet some higher-order functions, so these operations, is a time when packaging components of content to do.
Take the El-Table component as an example. When using the el-table component, it is necessary to write an El-table-column to display each column of data according to the composition of data and the content to be displayed. This operation is tedious and the number of code lines is redundant. It is common to copy the el-table-column column to modify the parameter, or to rewrite the el-table-column. Either way, it is tedious to write the code, so when encapsulating the component, We can reduce el-table-column or eliminate the writing of el-table-column as a point of entry. By doing so, we can identify one requirement point for the component to encapsulate. In the same way, we can identify the other requirement points for the component, and the question of what the component does is solved.
2. How to do
After identifying the requirements of the components in the first step, the next step is to design the scheme according to the requirements point by point, that is, how to realize the requirements. For the example above, reduce the user el-table-column or cancel the writing of el-table-column. We need to put the writing and rendering logic for el-table-column inside the component. Naturally, we can pass the column data into the component as a JSON string by passing parameters, and the component will loop through the data and generate the corresponding EL-table-column through a for loop. This completes the basic functionality of this requirement point.
/ / todo figure
Based on this, we can’t help but think that when rendering table data, sometimes we need to do more than just show the data, but do some extra processing, such as putting ICONS in front of the data, then the processing method just doesn’t meet the need. Element’s website provides an example of a slot for customizing column templates, which we can use when encapsulating components, with slots for customizing desired column templates.
3. How to do
The first two steps can be said to be the requirements collection and scheme design stage, then to this stage, is to carry out the actual coding stage, in this process, we are more to consider the technical level of the problem, that is, through specific code to achieve the above scheme design. Below are some of the design and techniques for passing parameters as you write components.
Design parameter
$attrsand$listeners
In the process of field components, for the operation of the fixed, and without user operation, is usually write a fixed value within the component directly, and users need a custom operation, the use of the parent-child communication transmission way, accept outside pass by prop, usually if the user doesn’t pass, the component will be set a default value achieves the effect of the default components. However, one problem we have to consider is that el-Table itself has many inputs and various effects. If we only expect the encapsulated components to have only part of the functions of El-Table, we can only pass in the parameters involved in these functions in the form of prop. But if you want to encapsulate some of the functionality while keeping the rest of the functionality of the El-Table component, then if you pass in the prop parameters one by one, the prop of the entire component will become extremely large and the amount of useless code will increase. Think of v-bind=”$attrs” and v-on=”$listeners”.
Here are $listeners and $attrs on vue’s website:
$attrs: contains attribute bindings (except class and style) that are not recognized (and retrieved) as prop in the parent scope. When a component does not declare any prop, all parent-scoped bindings (except class and style) are included, and internal components can be passed in via V-bind =”$attrs” — useful when creating higher-level components.
$Listeners: Contains V-on event listeners in the parent scope (without.native modifiers). Internal components can be passed in via V-on =”$Listeners “– useful for creating higher-level components.
Note that v-bind=”$attrs” and V-ON =”$listeners” are excellent tools for high order component encapsulation. Users pass parameters and methods of the EL-table into the components we package, and the components don’t need to process these parameters and methods. These contents are directly passed into the el-Table, and then the El-Table makes specific responses to these parameters and methods. It is not difficult to see that the customized component we encapsulated only acts as a middleware to receive external parameters and forward them to the El-Table. So that these operations of the el-Table themselves can be preserved.
Componentlisteners are passed prop for the parts they encapsulates and care about, and v-bind=”$attrs” and V-on =”$Listeners “for the parts they don’t care about or care about.
.sync
If the component is called a child component and the calling component is called a parent component, then the parent component passes arguments to the component via prop, the component exposes methods to the parent component via $emit, or marks the child component via ref. Parent component can use the vm. $refs. [r]. Child components of ref [subcomponents properties/methods] this way obtain child components data directly, this is also the general and his son components to communicate, but from the child component component as the data is passed to the father, father and son in the component data is still not every time synchronization, but in some special demand scenarios, We might expect the data in the parent and child components to be synchronized at all times. Take the el-Pagination component for example, current-page and page are imported from the outside. When the page number is switched and the number of pages per page is changed, we expect the external incoming current-page and page to be updated synchronously. .sync comes in handy. The official website about.sync
Release the component
Once packaged, components can be published to the NPM repository for others to use, and NPM packages can be published on their own. Two other points to be aware of when distributing an NPM package are the version number and documentation. The naming and updating of the version number are extremely important and cannot be ignored. In subsequent release and maintenance, pay attention to the setting of the version number and do not change it at will. Documents can be said to be the facade of components. Users generally use components through documents. Whether a document is written or not and how detailed the document is can directly affect users’ utilization rate and evaluation of components. Good documentation can also give developers a boost, for example, by gracefully responding to someone who says that your component doesn’t have a feature that doesn’t work, when in fact it does and the documentation details that feature.
