前言
在正式开始之前，我们先认识几个名词：
-
标准化 —— 统一度量衡
-
工程化 —— 实现量产
-
组件（Component） —— 造轮子
-
耦合 —— 衡量不同模块彼此间相互依赖的紧密程度
-
内聚 —— 衡量同一个模块内部的各个元素彼此结合的紧密程度
网上找了一些组件开发需要遵循的原则，这里参考下 www.cnblogs.com/ypppt/p/133…。
- 适用单一职责原则
- 适用开放封闭原则
- 追求短小精悍
- 避免太多参数
- 缩小信赖范围和向稳定方向信赖
- 适用SPOT法则 (Single Point Of Truth，就是尽量不要重复代码，出自《The Art of Unix Programming》)
- 追求无副作用
- 追求引用透明
- 避免暴露组件内部实现
- 避免直接操作DOM
- 适用好莱坞法则 (好莱坞法则： Don’t call us, we’ll call you, 又称IoC, Inversion of control, 控制反转)
- 入口处检查参数的有效性，出口处检查返回的正确性
- 充分隔离变化的部分
- 组件和数据分享，信赖一致性的数据结构
这篇文章写的也非常好，需要阅读下 zhuanlan.zhihu.com/p/78472109
正文
在日常的工作中，我们对组件开发已经有了比较详细的了解，但是目前开发的组件还有很多的缺陷，下面我们来由果及因，从具体使用需要来如何设计“好用”的组件。
- 根据之前讲解的更优雅的写页面——页面结构分析与规划 ，我们在开发之初，首先要详细了解需求，做好整体规划，确定目录结构、可复用内容与复用方式，一般在这一步，我们就能够知道需要设计哪些组件，他们的功能大概是要干什么
- 进一步分析要开发的组件是业务无关组件还是业务相关组件，明确各个组件后续的适用范围
- 业务无关组件可以作为工程通用组件使用，例如图片裁剪之类的组件。这类组件通用性要求更高，只处理一个明确的操作，哪怕换到其他项目里，也可以直接拿过去用。
- 业务相关组件是仅针对当前工程/页面制作的，将一些重复出现、相对独立的内容抽象出来，作为一个整体提供给后续页面使用，方便更清晰的划分结构和文件级别的精准代码维护。根据页面结构的规划情况，可以把一整个业务过程包括接口调用一起封装进去
- 到这里，需要开发哪些组件已经比较明确了，接下来就是组件的参数设计。
- 按照当前Vue工程开发习惯，为了更加清晰和便于维护，都是使用单文件组件。组件传参一般使用props，还有一种方式是使用method，写一个初始化函数，在外部调用函数时传参。
- 为了更加清晰和易用，组件参数建议使用props，并明确参数数据类型，使用尽可能少的参数，尽量避免使用object类型。同时，必输项和默认值按需要也要定义在组件内。
- 在组件设计时，一个重要的参考标志是功能边界，在设计之初就需要明确，这个组件是有哪些功能，哪些事情归他管，哪些事情归别的管，做好权限规划。一个组件与外界的联系尽量只通过参数props和事件event，父组件可以去访问子组件，子组件不能去找父组件/兄弟组件等，做好权限隔离。同时，样式方面也要控制好，只影响组件内部的样式，不能引入一个组件，结果把全局样式给修改了
- 业务相关组件有些显示单条数据详情的，需要仅用编码传参，不要从父组件带参数，根据需要可以在组件内调用接口查询数据。页面级的参数传递更是如此，保证每个页面的独立性，可以不管来源的使用，不能从列表点过来有数据，再次刷新或者把链接复制到其他地方打开就没数据了
- 要注意相对通用性，一个组件，再怎么通用，他都是一个专用工具，只能够满足很小的需求。要避免为了过分追求通用，把什么都做成可配置的，那样就和不使用组件差不多了，反而更加难用，过犹不及
- 通用性比较高的组件中，可以设计相对丰富的配置项，但同时也要设计绝大多数的默认值，让使用者仅仅传入最核心的参数即可使用。其他按需配置
- 每个组件的代码部分尽量短，如果发现过长，则需要想办法拆分成更细化的组件
Design > Coding
代码的结构设计远远大于开发了多少行代码，如果设计上有问题，写多少行代码都是 Bug ！
需求分析上更是如此，如果需求理解不清楚，开发多少错多少。
望大家三思而后行~
