组件设计
- 各种名称要尽量语义化、规范化，如组件名、参数名、方法名，语义化可以起到注释的作用，规范化保证系统各处命名规则一致
- 必要的容错处理，如没传参数、参数不正确等
- 常用的设置可以提取为缺省值
- 尽量提取出配置项，可预留用户自己定义内容的地方
- 场景化，如 dialog 的 success、warning 状态
- 可以拆分出子组件但不用过度组件化，适当的时候再分离也可以，维护良好的层次结构，可借助 StarUML 等工具画出组件图
- 扁平化、面向数据的 state/props，更加纯粹的 state 变化，这也是Redux推崇的，完全的扁平化设计能带来的开发体验和性能提升
- 考虑集中、统一的状态管理
- 提前考虑可扩展性，尽量做到后面的改变能向下兼容
- 分阶段、多版本维护，没必要一次就完成全部功能
- 维护详细的 CHANGELOG 或其它文档，能够记录变更历史
- 辅助代码分离，提取配置代码、假数据、非技术说明文档等
组件化规范
- 组件之间独立、松耦合
- 组件间嵌套使用
- 组件间通信
- 组件公用部分设计
- 组件的构建打包
- 组件继承与复用性
- 私有组件的统一管理
- 根据特性场景进行扩展或自定义
组件拆分
拆分依据
- 通常一个工程，由多个模块组成，每个模块由多个组件构成
- 可复用性，基础组件，方便统一管理，src/components
- 可维护性，拆分的依据一般是单一原则，分而治之，降低复杂度，src/views/xxx/components
- 可测试性，耦合度低到一定程度就可以了，没必要再无限制的拆分下去
- 适应UI设计师的建模
- 方便协作，有人控制逻辑，有人只写展示组件
- 不拆分是否有性能影响，使拆分后的组件更容易判断是否更新
- 考虑拆分的好处是否超过了成本
拆分方式
- 区分展示组件和容器组件，展示组件，通常没有自己的状态，只为展示信息，容器组件，有自己的状态、逻辑处理、数据绑定等，通常调用展示组件
- 切割复杂的 render() 方法，创建子组件
- 模板化组件，固定的东西放在模板组件中，业务组件进行逻辑处理后调用模板组件
- 高阶组件，做一层封装返回新组件