Componentization is a very frequently mentioned word now. I think componentization is to extract the greatest common divisor from the content of all pages. For example, background management and control project pages can basically be extracted into header, sidebar, container, and footer4 blocks, and then extract the greatest common divisor in each block, such as container. Form controls in the page, form controls, etc. There is no doubt that componentization is for the purpose of one-time implementation and permanent reuse, which not only facilitates your own development, but also allows other project and future partners to get started faster. When it comes to getting started faster, what kind of components can you get started faster? First, there are simple comments or documents in the component. Now editors can basically install doc-api plug-ins. Second, there are restrictions on the input parameters of components. The fewer the input parameters, the more parameter restrictions, and the easier it is to get started. For example, if a component only implements the function of the tab page, it is only allowed to pass an array representing the label to be displayed. A certain product needs to display more content. For example, if it is not satisfied with only displaying a label, it may display another title or other content. Then it may only need to add a few input parameters, and there is no need to make major changes to the components. But one day there is another demand for products, such as members, he wants to display member income, new members, per capita, new orders, payment order information, and the content to be displayed is different for each, in other words, each tab styles are different. Then it must be cumbersome if you only implement a tab component. So before doing it, have you considered the scalability of the components, and have you thought about whether the product will one day put forward some requirements that are generally consistent with changes in details. Then this component is replaced with two parts, one parent component represents the container of the tab, and the other child component represents a tab, the general structure is <tab-container><tab>a</tab><tab>b</tab></ tab-container> , so that each tab can implement its own content separately. However, in this way, the input parameters of the component will inevitably increase, and the limit of each parameter may be reduced. Knowing which parameters to upload in what scenario will increase the cost of starting the component. This may be a game about component scalability. , in the end whether to consider or reserve the extension of this function before writing this component. Another example is to disable a certain tab, whether it is disabled only once when the component is loaded, or to dynamically calculate or monitor this property, as long as the input parameters change, the disabled tab will be changed. It is unlikely that there is a need to dynamically change the disabled tab. If it is small, then there is no need to implement it in advance. A component has endless functions that can be extended. If it is implemented in this component forever, the final component will inevitably become bloated and unmaintainable. For example, a certain product requires the tab to add the sliding function, so that more tabs can be displayed by sliding. This requirement can be achieved by adding a type parameter, then assigning a default to represent the old tab, and then another value is scroll to achieve this requirement, but other possible types in the future will inevitably make this component difficult to maintain, so appropriate classification in advance, such as this sliding The general structure of the tab component is <tab-slider-container><tab-slider></tab-slider></tab-slider-contaner> In this way, different components are extracted according to the usage scenarios, then there are <tab> and <tab-slider> 2 tab components suitable for different scenarios.
Summarize the issues to be considered in componentization: 1. The structure of the component (whether the same function should be split into new components according to the scene, and the minimum granularity of the split is more appropriate), 2. The scalability of the component (whether to consider a function or not? expansion, to what extent.