什么是组件/模块
将页面中可复用的结构、样式和功能抽离成一个文件，便形成了一个组件或模块
组件、模块的定义
组件（Component）：偏向于从UI界面的角度进行划分；例如表格组件，表单组件。
模块（Module）：偏向于从功能、业务的角度进行划分；例如直播模块，聊天模块。
模块化是为了重用，是职责分离，将分属同一功能、业务的代码封装成独立的模块，这样就可以很方便的重复使用、快速组合使用到不同的系统中。
组件化是为了解耦，是高度可复用和对相关依赖的封装，将系统拆分成多个组件并确定组件的责任边界，便于后续升级和维护。组件功能相对单一，且更接近于底层。分为UI组件，业务组件
可以使用组件来组成模块，多个模块可以组合成业务
为什么要封装，封装解决了什么问题
- 高复用，低耦合：能实现业务功能拆分、复用，降低业务的耦合性；
- 关注点分离：使开发人员能更关注于业务本身；
- 提高维护性：有效的拆分、组织日益庞大的工程代码；
- 能力提升：对代码的封装性、合理性都有一定的要求，提升研发的设计能力；
- 灵活架构、快速交付：在积累、维护足够多的组件、模块的情况下，可以任意组合做出新产品；
表单、列表、分页组件组成具有搜索、分页功能的列表模块，列表模块加上业务数据组成了业务页面，在这种结构下，开发者只需要指定业务数据就能渲染出页面，而页面需要的其他功能如响应式，动态布局能均交由列表模块（各类组件）完成。大大提高了开发效率与可维护性。
封装思路、原则
重复就应该封装
划分粒度太小会提升维护成本，太大又不够灵活。
每一个组件都应该有其独特的划分目的的，有的是为了复用实现，有的是为了封装复杂度清晰业务实现。
建议阅读程序设计原则，简洁版如下：
- 职责单一
- 可以扩展，但不允许外部修改内部
- 避免太多参数
- 追求无副作用
- 追求引用透明（输出只依赖于其输入值，相同的输入得到相同的输出）
- 避免暴露组件内部实现
- 适用好莱坞法则 (好莱坞法则： Don’t call us, we’ll call you, 又称IoC, Inversion of control, 控制反转)
- 入口处校验参数的有效性，出口处校验返回的正确性
- 充分隔离变化的部分
- 避免直接操作DOM
- 保持一致性的数据结构
快速自查封装的是否合理
- 有必要再分？
- 依赖是否可再缩减？
- 是否对其它组件/模块造成影响？
- 是否可复用于其它类似场景中？
- 换位思考，使用这使用时会怎么想？
- 假如业务不需要这个功能了，是否方便清除？
