关于自建组件库的思考
很多公司都会有自己的组件库，但是在使用起来都不尽如人意，这里分享下我自己的一些观点和看法
问题思考
在规划这种整个团队都要用的工具之前要多思考，走一步想一步的方式是不可取的
首先，在开发一个组件库之前先要明确以下几点：
目前现状
不自建的话会有哪些问题，为什么不用 antd/element
哪些人提出了哪些的问题
分析为什么会出现这些问题
哪些问题是必须解决的，哪些是阶段推进的
期望目标
组件库的定位是什么
自建组件库是为了满足什么场景
阶段目标是什么
最终期望达到什么效果
具体实现
哪些问题用哪些方法来解决
关于后续迭代是怎么考虑的
目前现状
仅仅是因为前端开发为了部分代码或者样式不用重复写就封装一个组件甚至组件库是一件很搞笑的事情，最终往往会出现以下问题：
代码分散但是却高耦合，存在很多职责不明确
封装过于死板，且暴露的属性职责不明确
可维护性低，无法应对不断变化的需求
可靠性低，对上游数据不做错误处理，对下游使用者不做兼容处理
最后没法迭代，因为代码质量及版本问题，连原始开发者都改不动的，相关使用者怨声载道，然后又重构一遍，还是同样的设计思路，只不过基于已知业务场景改了写法，然后过一段时间又成为一个新的历史包袱。。。
当你为了方便改别人的代码而选择 fork 别人的组件库下来简单改改再输出时，难道你觉得别人不会对“你写的”这个组件库持同样的看法么？
你会发现，如果仅仅以一个业务员的角度去寻求解决办法的话，最后往往不能够得到其他业务员的认可的～
组件库的存在目的是为了提高团队的工作效率，不是单纯为了个别人能少写代码，前者才是目的，后者只是其中一种实现方式（这句话自己悟吧）
期望目标
一个合格的组件库应该要让使用者感受到两点：
约束（为什么只能这样传嘛？）
方便（只要这样传就可以耶～）
不合格的组件库往往只关注后者，但是其实前者更加重要
在能实现甲方的需求前提下，约束的树立会让团队对某一问题形成一个固有的解决方案，这个使用过程会促成惯性的产生
同时，这个惯性一旦建立，就能促成两个结果：
弥合了人与人之间的差异
提高了交流效率（不单单是开发，还包括设计、产品、测试等一条工作链路上的相关人）
要知道的是，团队合作过程中，效率最低的环节永远是沟通，一个好的团队不是全员大神，而是做什么事情以一个整体，每个人步调趋于一致，这样效率才高～
具体实现
编写一个公共库需要考虑很多东西，下面主要分三点来阐述
逻辑的分割
避免一次性、不通用、没必要的封装
不允许出现相互跨级或交叉引用的情况，应形成明确的上下级关系
被抽离的逻辑代码应该尽可能的“独立“，避免变成”谁也离不开谁”
逻辑的封装
对于一个管理平台框架来说，宗旨是让开发少写代码、产品少写文档，不需要每次有新业务都要重复产出
对于开发来说，具体有两点：
大部分情况下，能拷贝下 demo 即可实现各类交互效果
小部分情况下，组件能提供其他更多的可能以满足特殊需求
封装过程中，仅暴露关键属性，提供多种可能，并且以比较常用的值作为“默认值”并明确定义，即可满足“大部分需求只需无脑引用，同时小部分的特殊需求也能被满足”
维护与开发
作为一个上游的 UI 库，要充分考虑下游使用者的情况
做到升级后保证下游大部分情况下不需要改动
组件的新增、删除、修改要有充分的理由（需求或 bug），并且要遵循最小影响原则
组件的设计要充分考虑日后可能发生的变化
未来展望
仅靠一个 UI 框架难以解决问题，对于未来的想法有分成三个阶段：
UI 库，沉淀稳定高效的组件
代码片段生成器，收集业务案例代码
页面生成器，输出有效模版
这里更多面向的是中后台项目的解决方案
总结
组件库输出约束和统一解决办法，前者通过抚平团队中个体的差异来提高团队的沟通效率，后者通过形成工作惯性来提高团队的工作效率
作者：tellyourmad
来源：juejin.cn/post/7063017892714905608
