组件化已经无处不在。可能每个人一张嘴都是组件化模块化。

这个时候我们能否认真回想一下，自己的组件，真的是组件化了吗？

怎样的组件化才算比较好的组件化？

根据客观事实（主要是主观臆想），浅谈一下前端的组件化。

1、组件化的使用背景

业务的迭代和堆积

1、单个文件有成千上万行代码，可读性非常差，维护也不方便

2、有大量重复的代码，相同或者类似的功能实现了很多遍

3、新功能的开发成本巨大

4、不敢重构，牵一发而动全身

场景的多样化

1、不同的项目，类似的场景

2、相同的项目，越来越多的场景

背景和场景都有了。

如何判断你的代码质量如何？

一个比较直观（其实也是我的主观）的判断就是：2年后我是否还能轻易维护或者复用你的代码。

如果举步维艰，那我们应该好好想想，什么才是组件化？

2、组件化的定义和特性

（蹩脚的）定义

组件化 就是将UI、样式以及其实现的比较完整的功能作为独立的整体，

无关业务，

无论将这个整体放在哪里去使用，

它都具有一样的功能和UI，

从而达到复用的效果，

这种体系化的思想就是组件化。

特性——高内聚，低耦合

一个组件中包含了完整视图结构，样式表以及交互逻辑。

它是封闭的结构，对外提供属性的输入用来满足用户的多样化需求，

对内自己管理内部状态来满足自己的交互需求，

一言蔽之就是：高内聚，低耦合。

组件化的目的

减少重复造轮子（虽然造轮子是避免不了的事）、反复修轮胎（疲于奔命迭代维护组件）的频率，

增加代码复用性和灵活性，提高系统设计，从而提高开发效率。

说完组件化的基本定义和特性，接下来就说说组件化的分类吧。

3、组件的分类

分类的形式可能有多种和多角度，我这里按自己的日常（react技术栈）使用分一下。

函数组件和类组件

1、函数组件的写法要比类组件简洁

2、类组件比函数组件功能更加强大

类组件可以维护自身的状态变量，还有不同的生命周期方法，

可以让开发者能够在组件的不同阶段（挂载、更新、卸载），

对组件做更多的控制。

ps：自从hooks出来以后， 函数组件也能实现生命周期等更多骚操作了。

自己的使用原则：

如果功能相对简单简洁，就是用函数组件；

功能丰富多样，相对复杂就使用类组件。

界限不是特别清晰，但是大的基本原则是这个，仅供参考。

展示型组件和容器型组件

1、展示型组件像个父亲（父爱如山，一动不动，他真的不动！）

不用理会数据是怎么来到哪里去，

它只管兵来将挡，水来土掩，

你给我什么数据，就就拿它来渲染成相应的UI即可。

2、容器型组件则像个老师。

他需要知道如何获取学生（子组件）所需数据，

以及这些数据的处理逻辑，

并把数据和使用方法（处理逻辑）通过props提供给学生（子组件）使用。

ps：容器型组件一般是有状态组件，因为它们需要管理页面所需数据。

无状态组件和有状态组件

1、无状态组件内部不维护自身的state（因为它根本就没使用），

只根据外部组件传入的props返回待渲染的元素（传说中的饭来张口，衣来伸手？）。

2、有状态组件维护自身状态的变化，

并且根据外部组件传入的props和自身的state，

共同决定最终渲染的元素（自给自足，别人也来者不拒）

高阶组件

任性，就是不说，自己百度谷歌一下...

说完分类，说说使用了组件化以后有啥好处。

4、组件化的价值

业务价值

1、组件与具体场景或业务解耦，提升开发效率与降低风险，促进业务安全、快速迭代

2、提高了组件的复用和可移植，减少开发人力

3、方便测试模拟接口数据

4、便于堆积木般快速组合不同的场景和业务

技术价值

1、组件与框架解耦，去中心化的开发，这背后其实是一种前端微服务化的思想；

2、页面资源可以动态按需加载，提升性能；

3、组件可持续，可自由组合，提升开发效率；

O了，说得组件化这么好，那我们设计组件前，应该思考什么问题呢？

5、开发组件前的灵魂拷问？

组件应该如何划分，划分的粒度标准是什么？

组件划分的依据通常是业务逻辑和功能，

一段相对完整且完备的功能逻辑就是划分的一个界限。
当然，你还要考虑各组件之间的关系是否明确以及组件的可复用度等等。

这个组件还能再减吗，它还能减少不必要的代码和依赖吗？

越简单的组件，往往具备越容易复用的特性。
你看各大知名UI库组件库，
他们设计出来的轮子是不是几乎都差不多？
都是按钮，弹窗，提示框等等？
而那些看起来功能超级丰富的组件，往往使用的场景反而很少？

此组件是不是渣男？是不是到处去破坏别的组件，入侵其他组件却挥一挥衣袖，留下了一堆云彩？

如果一个组件的封装性不够好，或者实现自身的越界操作，

就可能对自身之外造成了侵入，这种情况应该尽量避免。

确保组件的生命周期能够对其影响进行有效的管理（如destroy后不留痕迹）。

举个栗子： 如果你的组件触发了鼠标滚轮事件，一滚轮就打断点，或者不断的加数据到内存中。

直到组件被销毁了，还没有去掉这个事件的处理，那就可能导致内存泄漏等等情况了，渣男...

是否便于拔插，就是来去自如的意思，复用方便，删除随便？

1、组件设计需要考虑需要适用的不同场景，

在组件设计时进行必要的兼容。

2、各组件之前以组合的关系互相配合，

也是对功能需求的模块化抽象，

当需求变化时可以将实现以模块粒度进行调整。

3、设计组件时要想想如何快速接入，快速删除，但是又不影响别的组件和业务。

6、组件化的设计原则和标准

不说了，打字打累了，直接上图 （有图有真相）

PS：这个标准和原则来源于网络（图是我的图），我看到的时候表示默默认同，记下来了，再截图出来。如果侵权，请告诉我删除。

组件化，你今天想好了吗？