如何去设计一个组件封装_前端组件化设计思路

目前前端三大框架（vue.js, Angular.js, react.js）都在引领着前端的组件化开发方向，组件化的前端开发方式的确为业务实现带来了前所未有的方便，其实组件化开发早已经具有（YUI），但如何封装一个优秀的组件，可能并不是每位前端开发者都能够做好的。

组件封装有一定的不确定性，更多时候是在做几个方面的权衡，并且在业务不断变化中，可能还会面临一些调整和重构。

组件化开发的意义有很多，一些新手会狭隘地认为只是为了复用（包括对于模块化的理解），认为只有一个地方用就没必要抽取封装为组件，但实则不尽然：

• 组件化是对实现的分层，是更有效地代码组合方式
• 组件化是对资源的重组和优化，从而使项目资源管理更合理
• 组件化有利于单元测试
• 组件化对重构较友好

组件与模块

模块(Module)通常强调的是职责（分离、内聚），组件是可复用模块和相关依赖的封装。

组件可以如下定义：

• 可复用的模块，完成既定功能
• 有明确的接口规定
• 有上下文依赖、外部依赖资源的定义
• 可以独立发布

组件设计的原则

新手常常会更多地从实现（如所用的框架vue的组件实现方式）直觉角度定义组件，并且隘于视角较局限，经验较欠缺，对于职责划分不合理。

以下原则尽可能使用，用得越多就组件的复用性就越好。

1. 适用单一职责原则
2. 适用开放封闭原则
3. 追求短小精悍
4. 避免太多参数
5. 缩小信赖范围和向稳定方向信赖
6. 适用SPOT法则 (Single Point Of Truth，就是尽量不要重复代码，出自《The Art of Unix Programming》)
7. 追求无副作用
8. 追求引用透明
9. 避免暴露组件内部实现
10. 避免直接操作DOM
11. 适用好莱坞法则 (好莱坞法则： Don’t call us, we’ll call you, 又称IoC, Inversion of control, 控制反转)
12. 入口处检查参数的有效性，出口处检查返回的正确性
13. 充分隔离变化的部分
14. 组件和数据分享，信赖一致性的数据结构

自省的几个问题

以上原则有点太教科书，不结合长期的实践深刻理解，很难灵活运用，所以我设计了以下几个自省问题，在思考一个组件时候，从这几个问题入手，引导完善组件的设计。

这个组件可否（有必要）再分？

组件划分的依据通常是 业务逻辑、功能，要考虑各组件之间的关系是否明确（如组件树方式管理组件间依赖关系，兄弟组件不可见），以及组件的可复用度。

虎课网https://www.wode007.com/sites/73267.html 设计坞https://www.wode007.com/sites/73738.html

划分粒度的大小需要根据实际情况权衡，太小会提升维护成本，太大又不够灵活和高复用性。

每一个组件都应该有其独特的划分目的的，有的是为了复用实现，有的是为了封装复杂度清晰业务实现。

这个组件的依赖是否可再缩减？

缩减组件依赖可以提高组件的可复用度，常用的方法是IoC（依赖注入），对外弱类型依赖。

这个组件是否对其它组件造成侵入？

一个组件的封装性不够，或者自身越界操作，就可能对自身之外造成了侵入，这种情况应该尽量避免，确保组件的生命周期能够对其影响进行有效的管理（如destroy后不留痕迹）。

较常见的一种情况是：组件运行时对window对象添加resize监听事件以实现组件响应视窗尺寸变化事件，这种需求的更好替代方案是：组件提供刷新方法，由父组件实现调用（最终由根组件统一处理）。

次优的方案是，当组件destroy前清理恢复。

一个组件不应对其它兄弟组件造成直接影响。

这个组件可否复用于其它类似场景中？

需要考虑需要适用的不同场景，在组件接口设计时进行必要的兼容。

这个组件当别人用时，会怎么想？

接口设计符合规范和大众习惯，尽量让别人用起来简单易上手，易上手是指更符合直觉。

假如业务需要不需要这个功能，是否方便清除？

各组件之前以组合的关系互相配合，也是对功能需求的模块化抽象，当需求变化时可以将实现以模块粒度进行调整。