分享主要以Scrum的方式去思考，并通过引出对应的问题来进行。

场白：

    公司业务量阶梯式增长，项目增多，带来的重复工作也越来越庞大，为了解决这个痛点，便有了项目的标准化、组件化，乃至插件化等思想。

这些思想的核心做的都是规整、自理沉淀业务的工作，从业务而来，为业务服务。

一、封装初衷

1. 代码复用
2. 逻辑复用
3. 统一维护
4. ....

可拖拽、编辑、多层级嵌套Table 封装后的代码示例

二、封装原则

透明、适应、检查

1、价值驱动

简单来说就是为了解决什么问题而封装这个组件。

2、适应变化

开始可能只是为了解决某个问题而封装，后面可能出现在这个基础上的定制，所以要前后兼容，适应变化。

3、自组织

自组织，就是组件内部，或者组件之间分开可以各自工作，组合在一起可以达到更高的威力。

但自组织的前提是内部必须有一套自己的运行规则，也就是说组织的边界在哪里。

================================

**由上面三个问题得到组件的基本原则：就是目的明确（纯净），能自行稳定运行，且自发处理异常**

================================

三、封装过程

1、结果导向

    清楚明确的知道这个组件是做什么用的。

很多时候都是写页面的时候不会考虑封装，发现有重复内容时，才会为了复用而封装成组件。

2、技术选型

    如果事先能知道接下来要做什么，会有一个技术选型的过程，并且可以有预演、容错的判断。

    这中间就是技术选型。

    甚至后面有了更好的选择，也是一个选型的过程。

    选型的过程核心是**成本的控制**。

3、原子粒度

    就是封装这个组件，可能会用到那些标签，这些标签就是原子。

    原子可以是最细原始html标签，也可以是封装好的组件。

    这里的粒度，或者说层级，指的是用户在用这个组件的时候，用户想知道你的底层逻辑，他/她需要往下找多少层，才能找到**处理核心逻辑的地方**。

    层级一般不推荐超过三层，但是到了第三层，可以有同级的处理应用。

粒度

4、数据传递

    就是组件如果需要接收数据，这个数据来自于哪里。

    如果数据不是自身产生并在内部维护，当数据需要被更新时，应该保持唯一原则：**谁生产，谁维护**。

5、状态管理

    比如一个下拉选择框，点击下拉的时候弹出的框，其实也是一个状态。

1. 内部状态：

    这个状态表示的是内部的一些state的值，状态管理，就是这些**组件内部state值的更新以及维护**。
   

2. 关联状态：

   有些组件的状态既可以内部维护，也可以被父组件感知，并由父组件更新，叫关联状态。

状态关联

3. 共享状态：

   就是多组件共享的状态。

    比如cookie、storage以及vue的vuex，react的redux，等等。
   

6、能效

性能范畴比较大，当前只讨论当前组件的封装后的性能问题。

这里的能效，指的是组件自身的性能，以及用户使用这个组件的成本、效率。

    对前端开发而言，我个人觉得最能反映一个项目的成败，是这个项目的性能是否足够高效。

• 性能

    对于组件的封装，子组件层级过深的时候，比如在react中，一旦父组件的state等引起更新，整个组件树就可能都会被重新计算、渲染。
  
    对组件的操作就是**赋值、变值**的过程，想办法以**最小的开销，完成更多的事情**，就是性能优化。
  
    一旦层级过深或者组件内聚条件过于复杂，很难兼顾各种情况在当前组件做好性能优化。
  

下面如react演示，如果需要，可以在用的当前父组件添加一层封装，在当前封装的基础上做性能。

// 子组件
const Item = props => <DragItem {...props} />;
export default Item


// 父组件
// 性能优化
// (这里同样会有问题，如果数据改变但是index没改变，同样不会触发更新)
function areEqual(pre, next) {
  let flag_index = pre.index === next.index;

  return flag_index;
}
export default memo(props => {
  return <Item {...props} />;
}, areEqual);

• 成效

  比如用户使用这个组件能否直接达到目的、如有定制能否很容易扩展、如果用户使用错误对应错误如何处理等等。

  image.png

四、组件维护

    在`Scrum`中有一个概念叫**增量**。

    简单理解就是把一个组件最终要做或者最终可能要做的事情分成多个版本完成，每个版本完成后的成果就叫一个增量。

    版本核心是**聚焦当前**。

    所以就可以引出以下问题：

1、组件的结果导向边界

2、当前的边界在哪，前后兼容的边界节点

3、...

    以及：

1、异常处理

2、版本迭代（增量）

3、...

五、命名/等约束

1. 语义化、大驼峰、常量全大写...
2. 代码量、
3. 类型、

六、More

1. 更好的建议
2. 更好的控制
3. 更好...

FAQ

前端 Plug-in

前端插件化

    在现在的前端来讲，页面展示的所有标签都可以看成是一个组件，哪怕是一个空的div，也可以是一个组件。

    不管VUE还是REACT或者ANGULAR，都是组件驱动，按需加载，但这种按需的代码是已经被写入到主程序里面了的。

    和组件思想不同的是：

• 前端plugin的plugin本身可以但不止于是组件，也可以是浏览器任何能接收的东西，比如逻辑代码、比如json数据、比如埋点等等。
• 而且最重要的是，前端plugin是插拔式的，也就是只有想用的时候，才会去从别的服务器下载，而不是一开始就在主程序包里面。

暂时的思路：是插件按照一定规范生成，推送到指定服务器，然后主程序通过约定的方式，下载对应的js包，根据约定字段，插入到对应的位置，完成plugin的装载。

更优技术方案：待定...