你好，想提前下班吗？“前端UI模块化”了解一下

Posted 2021-04-27 腾讯FiTdesign

【严究设计】是腾讯FiT designer的短平快设计思考。在这里你可以看到设计师的一些日常活动，对工作、对设计的一些个人感悟或者小思考，还能发现FiT designer工作生活中的创意活力。

---

前端模块化/组件化是个老生常谈的话题，不同时间段、不同团队和个人对它的见解和使用也多种多样。

这里，我根据自己的工作经验，把一个易用、健壮的模块/组件要具备的特性规整为通用性、移植性、扩展性、维护性和兼容性五个属性。

由于我从事的是重构工作，这篇总结会偏重构视角（也即UI视角）多些，欢迎有不同看法的重构、前端小伙伴补充、探讨。

五属展开之前，我们先来明确下定义。知乎、百度了一圈儿，发现对于模块和组件的定义五花八门，只是没有一个可以直接拷贝过来的。好吧，那我就针对接下来要讲的，明确一下它们在本文中的概念吧。

组件——可以独立完成某个功能的代码的集合。用人话讲就是要实现某个功能，比如下图中的日期联动选择器，所需要的结构、样式、逻辑以及资源（如图片）的集合。

组件代码— 完整无冗余的结构、样式及逻辑

模块——模块仅限于展现层面，比起组件，少了逻辑这一层的添加。如：

模块代码— 完整无冗余的结构及样式

为什么要写公共模块或者组件呢？举个栗子，比如页面里常用的按钮：

在A页面里出现了，实现了一套，B页面里又出现了，怎么办？重新写一套？or从A里面拷过来用？

如果A页面里的是别人实现的，而且代码很不规范，很难扒过来，你可能就按照自己的喜好和习惯重新写一套了。如果A页面里是你自己早前实现的，你很可能就把它拷到B页面来用了。那么问题来了，如果某一天这个按钮要改了，比如改成下图这样子：

而这时经历了长期的版本迭代和多人合作，页面C、页面D、页面E……等十几甚至几十个页面都私有实现了自己的按钮（尽管它们在展现上看起来是一样的），而且页面C和页面E的实现是一样的，页面D和页面A的是一样的，页面B是单独自己一套的……，此时，你如何去改？

所以，公共模块和组件的意义就在于，写一套标准的、可扩展的公共代码，供所有需要它的场景复用。这样不仅复用它的场景不用再重复实现，而且需要修改的时候可以一改全改。简直就是一本万利、一劳永逸，有没有？

说到底，模块和组件的核心价值在于复用，复用门槛越低，它被复用的频次可能就越高；复用频次越高，它发挥的价值就越大。那如何才能降低门槛、提高频次呢？下面就从上文提到的通用性、移植性、扩展性、维护性、兼容性和安全性五个属性入手，来聊聊这个问题。

通用，即大家都能用。

通用性，这里分场景通用性和框架通用性两个方面。

>>场景通用性

场景通用性，即这个功能被用到的概率要高。比如这个h5页面中常见的提示弹窗，几乎没有哪个h5的应用不需要它，它的通用性就高。

再如，某次活动你开发了个Angry Bird的小游戏，不大可能你情人节用了，中秋节再用；也不大可能A项目用了，B项目、C项目也用，因为这个功能是属于创意类的，你反反复复用估计用户都要变成Angry Bird了。那么，这个小游戏的通用性就低。

但是，它里面的某些小功能是具有高通用性的，比如Bird运动轨迹的抛物曲线，在很多需要曲线运动的动画中都可以复用。

所以我们说，Angry Bird小游戏的通用性低，但它里面的抛物曲线的通用性高。

>>框架通用性

框架通用性，顾名思义，就是要跨站复用的模块/组件尽量不用框架或者用当前比较通用的框架。不然，模块/组件写的再好，框架不同，气场不合，别人也是没法复用的。

比如下图中这个不依赖任何框架的环形渐变进度条通用性就高：

这个依赖zepto的双头滑块控件框架通用性就相对低点：

既然写模块/组件是为了复用的，那么，它必须易于移植到其他场景，并且移植过去之后不会出问题才行。

易于移植，就需要做好封装。移植之后不会出问题，就要保持独立性。

>>封装性

封装有两层含义，一个是代码的封装，一个是接口的封装。

代码的封装，即这个模块/组件用到的代码可以单独拎出来，而不受环境中其他代码的影响。

接口的封装，指的是调用这个组件所用的接口和参数，是否已提炼出来。做好了接口封装，调用的人便不用去研究这个组件是如何实现的，只需通过接口配置自己需要的参数就可以了。就好像日常所用的电器一样，你不用管它内部是如何实现的，你只要按下“开”，它便会打开，你设置自己想要的功能，它便会按你所设置的参数去运行。

做好了封装的组件，如下图所示：

使用时你只需要把这个组件的代码包部署到自己的环境下，然后根据自己想要展现的功能传递参数，运行接口函数即可。

>>独立性

独立性主要体现在平台无关性和低耦合两个方面。

平台无关性，即这个模块/组件的实现不依赖平台，它在这个平台上可以用，在那个平台上也可以用。

低耦合，这个大家都很熟悉了，一个好的模块/组件一定是高内聚低耦合的。在模块/组件建立之初，就要做好规划和拆分，保持模块/组件间的独立性，不能你中有我，我中有你。另外，命名方面，也要通过命名空间、长命名等方式做好作用域的限制。常见的如class、id、资源文件名的命名带上一些公共的标识符，以免和目标场景中原有的一些命名重合而导致互相影响。

比如，对于公共模块的容器节点，统一加一个”mod-“前缀class，而且对于这个模块的所有样式，都要带上这个class来限制作用域。如下图的步骤导航模块：

扩展性，即模块/组件要尽可能地自适应目标场景的一些因素，比如尺寸，位置，可预见的一些变更等。

比如下图这个步骤指引模块，不管文字多少，条目多少，都是可以自适应的：

但是呢，再严谨的人，都可能百密一疏。再有远见的人，都没法准确预测每个目标场景的私有情况。所以，除了自适应外，模块/组件还必须可以重置，以便目标场景可以根据自己的需要更改一些东西。

比如这个PC端常用的表单模块，默认情况下展现是这样的：

但某些场景，比如在弹窗中引入表单时，因为尺寸限制，需要把文字和间距调小：

这种时候，我们就可以在模块样式里为它添加一个扩展类，如ext-form-mini，通过这个class来重置样式：

目标场景的用户取用的时候，可以根据自己的需要自行取舍，需要标准版表单的就只用默认结构即可，需要迷你版表单的就在默认结构的容器节点上添加class “ext-form-mini”：

当然，有些目标场景可能还需要根据自己的特征做些私有调整，这时，只需在容器节点上再添加一个私有类，如“new-form-xxx”，通过这个class来重置样式即可。

维护性主要体现在规范化和注释两个方面。

规范化是为了多人合作的时候能够如一个人一样顺滑。比如上面举例过的提示弹窗模块和步骤导航模块，是不同人写的，但是它们的代码风格、命名方式、作用域限定等都是一致的。这样，在互相取用甚至互相接手维护的时候就会特别容易，即易读、易用、易改。

规范的内容可以涵盖方方面面，一般来说，每个团队都会有自己的规范，它是团队智慧的结晶，代表着团队公认的最普适或者最优的解决方案。

关于注释，不用解释，大家都知道它的重要性。我写代码的时候 ，我和上帝知道什么我写的什么，过了一个月就只有上帝知道写的什么了。

可是知不知道是一回事，想不想写是另外一回事。程序猿最讨厌的四件事嘛：

                // 写注释

                // 写文档

                // 别人不写注释

                // 别人不写文档

哈哈，即便讨厌，也要克制自己，看看下面这简单明了的注释，你有没有冲动去改下参数试试效果呢：

另外，关于注释，还有一点需要注意又特别容易被忽略的，那就是注释里不能有别人不该看到的信息，尤其是代码给团队外部复用时要特别注意。

比如去年某宝的代码文档里出现微信开发gg的名字：

后面的事大家都知道了。

所以，模块/组件写好后，要认真检查下代码、注释里有没有人名、产品信息、组织信息、涉及版权的内容等等。

兼容性应该是前端码农最大的痛了，没有之一。好容易写好的模块/组件，在自己电脑或者手机上看了下，美美哒：

低端测试机上再看下：

如果砸手机可以解决问题：

一定将测试机和产品的手机砸得永世不得超生。

好了，发泄完了，问题还是要解决。兼容性解决得越好，模块/组件被复用的几率就越大。如果有些问题实在没法解决，起码给低端机一个平稳退化的方案。

文章整理出来后，给老大过目，老大摸了摸他那一有机会就必秀的八块腹肌，说：“不错！用好模块化和组件化，就可以把时间浪费在一切美好的事情上了。”

---