组件化是现在提的频率非常高的一个词。我觉得组件化就是从所有页面的内容去提取最大公约数，例如后台管控类项目页面基本都可以提取为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个适用于不同场景的页签组件。
总结一下组件化要考虑的问题：1、组件的结构（同一个功能要不要根据场景拆分新的组件，拆分的最小粒度多少合适），2、组件的扩展性（要不要考虑某个功能的扩展，扩展到什么程度为。