我对组件化的一点细琐的想法

 

　　组件化是如今提的频率很是高的一个词。我以为组件化就是从全部页面的内容去提取最大公约数，例如后台管控类项目页面基本均可以提取为header，sidebar，container，footer4大块，而后在每一块里再提取最大公约数，例如container页面里的表格控件，表单控件等。毫无疑问，组件化是为了一次实现，永久复用的效果，这样不只是方便了本身开发，也让项目其余的和将来的小伙伴更快的上手。提到更快上手，那么什么样的组件才能更快的上手，一是组件内简单的注释或者文档，如今的编辑器基本均可以装doc-api的插件，二是组件的入参的限制，入参越少，参数限制越多，上手越简单。好比某个组件仅仅实现了tab页签的功能，那么只容许传一个表明要显示文案的label的数组就能够了。某个需求产品要多显示一些内容，好比不知足于只显示一个label，可能要再多显示一个title或者其它什么内容，那么可能也仅仅须要加几个入参，并不须要对组件大变更。可是某天产品又一个需求，例如会员，他要展现会员收入，新增会员，人均，新增订单，支付订单的信息，而且每一个要展现的内容都不太同样，换句话说每一个tab的样式都不同。那么你仅仅一个tab组件来实现的话确定很繁琐。那么在作以前有没有考虑到组件的可扩展性，有没有去思考产品哪天又会拍脑壳提出某些大致一致，细节有变化的要求。那么这个组件换成2部分，一个父组件表明tab的容器，另外一个子组件表明一个tab，大体结构就是<tab-container><tab>a</tab><tab>b</tab></tab-container>，这样就能够对每一个tab能够单独实现本身的内容。可是这样一来，组件的入参势必会变多，可能每一个参数的限制也会变少，了解什么场景上传什么参数就会提升组件的上手成本，这多是一个关于组件可扩展性的博弈，到底在写这个组件前要不要考虑或者预留这个功能的扩展。又好比某个tab要禁用，是仅仅组件加载时禁用一次，仍是动态去计算或者监听这个属性，只要入参改变就会改变禁用的tab。出现动态改变禁用tab的需求可能性大不大，若是很小，那么就不必去预先实现。一个组件有能够扩展不完的功能，若是永远在这个组件中实现，那么最终组件必然会变得臃肿不堪维护。好比某个需求产品要求tab加入滑动的功能，这样就能够经过滑动显示更多的tab。能够经过加一个type入参，而后赋予一个default表明老的tab，而后另一个值是scroll来实现这个需求，可是之后可能的其余type势必让这个组件难以维护，因此提早适当的分类，好比这个滑动的tab组件大体结构为<tab-slider-container><tab-slider></tab-slider></tab-slider-contaner>这样按照使用的场景提取出不一样组件，那么就有了<tab>和<tab-slider>2个适用于不一样场景的页签组件。

　　总结一下组件化要考虑的问题：一、组件的结构（同一个功能要不要根据场景拆分新的组件，拆分的最小粒度多少合适），二、组件的扩展性（要不要考虑某个功能的扩展，扩展到什么程度为。