Published on

前端组件化思想

Authors
  • avatar
    Name
    Pursue
    Twitter

1.开篇

先说说为什么要写这篇文章吧：不知从什么时候开始，大家相信前端摩尔定律：“每 18 个月，前端难度会增加一倍”。我并不完全认可这个数字的可靠性，但是这句话的本意我还是非常肯定的。

是的，前端越来越简单了，但也越来越复杂了---简单到你可以用一个Github的starter搭建一个框架，集成所有的全家桶，涵盖单元测试和功能测试，包括部署以及发布，甚至你开发时使用的 UI 库都让你写不了几行css；可又复杂到如此多的框架和库层出不穷，你还没来得及学会官网的 doc 呢，就已经有新的替代品了，那就更别提静下心去学习其中的源码或推敲原理了，跟不上脚步强行搬砖自然略显疲惫。

正是前端飞速的发展使得前端看似简单，但若想深入却实属不易。顺便提一句，去年 6 月底，ES8已经发布了，没错，你没看错，是不感觉学不动了（开玩笑了，其实也没更新啥，不会再有ES5->ES6这种跨度了）。

所以，我近期觉得使用的框架有些多了，得静下心来沉淀沉淀---为什么要说写组件化思想呢？因为我觉得它是伴随着前端发展的一个不可或缺的设计细想，目前几大流行框架也都非常好的实现了组件化，比如React，Vue。React之前用得算是比较多了，所以本篇我决定以Vue作为基础，去谈一谈前端模块化，组件化，可维护化的设计细想。

2.什么是组件化

组件化并不是前端所特有的，一些其他的语言或者桌面程序等，有具有组件化的先例。确切的说，只要有 UI 层的展示，就必定有可以组件化的地方。简单来说，组件就是将一段 UI 样式和其对应的功能作为独立的整体去看待，无论这个整体放在哪里去使用，它都具有一样的功能和样式，从而实现复用，这种整体化的细想就是组件化。不难看出，组件化设计就是为了增加复用性，灵活性，提高系统设计，从而提高开发效率。

3.组件化的演变

如果你对 JS 的理解还停留在jQuery的话（jQuery本身是一个非常优秀的库），那么请跳过此文（开个玩笑）。在那个时候，大部分的前端开发应该都是十分过程式的开发：操作DOM，发起ajax请求，刷新数据，局部更新页面。这样的动作反反复复，甚至在同一个项目里同样的流程也许还要重复，其实jQuery本身也有有自己模块化的设计，有时我们也会用到类似jQuery UI等不错的库来减少工作量，但请注意，这里我只认为它是模块化的。

频繁操作 DOM，过程式的开发方式的确不怎么样。这时开始流行MV*，比如MVC，前端开始学习后端的思想，讲业务逻辑，UI，功能，可以按照不同的文件去划分，结构清晰，设计明了，开发起来也不错。在这个基础上，又有了更加不错的MVVM框架，它的出现，更加简化了前端的操作，并且将前端的 UI 赋予了真实意义：你所看到的任何 UI，应该都对应其相应的ViewModel，即你看到的view就是真实的数据，并且实现了双向绑定，只要 UI 改变，UI 所对应的数据也改变，反之亦然。这的确很方便，但大部分的MVVM框架，并没有实现组件化，或者说没有很好的实现组件化，因为MVVM最大的问题就是：

  • 1.执行效率，只要数据改变，它下面所有监测数据上绑定的 UI 一般都会去更新，效率很低，如果你操作频繁，很可能调了几十万遍（有可能层次太深或者监测了太多的数据变化）。

  • 2.由于MVVM一般需要严格的ViewModel的作用域，因此大部分情况不支持多次绑定，或者只允许绑定一个根节点做为顶层 DOM 渲染，这就给组件化带来了困难（不能独立的去绑定部分 UI）。

而后，在此基础上，一些新的前端框架“取其精华，去其糟粕”，开始大力推广前端组件化的开发方式，从这一点来说，React和Vue是类似的。

但从框架本身来说，React和Vue是完全不同的，前者是单向数据流管理设计的先驱，如果非让我做一个不恰当的比较的话，我觉得React+Redux是将MVC做到了极致（action->request, reducer->controller）；而后者则是后起之秀，既吸取了React的数据流管理方式（Vue本身也可以用类似React去开发，但难度比较大而已，不是很Vue）的设计理念，也实现了MVVM的双向绑定和数据监控（这应该是Vue的核心了），所以Vue是比较灵活的，可以按需扩展，它才敢称自己是渐进式框架。

PS1: 并非讨论孰好孰坏，两大框架我都很喜欢。

PS2: 上面有提到模块化，个人觉得如果更广义的来讲，模块化和组件化并不在一个维度上，模块化往往是代码的设计和项目结构的设计；但很多时候在狭义的场景中，比如一个很通用的功能，也完全能够将其组件化或模块化，这两者此时十分相似，最大的区别就是组件必定是模块化的，并且往往需要实例化，也应当赋有生命周期，而模块化往往是直接引用。

4.如何实现组件化

我就以搜房网为例(最近房价居高不下，各个大佬还在吹各种牛 x 说房价不久后将白菜价，我顺便 mark 下看以后打谁的脸)进行 demo 分析。随手截图如下：

4.1 分析页面布局

从大体上来看，可以分为顶部搜索，中间内容展示。而中间内容又分为 part1，2，3 三种类型。由于篇幅问题，本文只分析 part1，2，3

每一个 part 中又可以分为 header(title + link)和 content(每个 part 不一样)

4.2 初步开发

如果没有经过任何设计，也许会出现下面的代码：

<template>
  <div id="app">
    <div class="nav-search">...</div>
    <div class="panel">
      <div class="part1 left">
        <div>
          <span>万科城润园楼盘动态</span>
          <a href="">更多动态>></a>
        </div>
        <div>这里是每个part里面的具体内容</div>
      </div>
      <div class="part2 right">
        <div>
          <span>楼盘故事</span>
          <a href="">更多>></a>
        </div>
        <div>这里是每个part里面的具体内容</div>
      </div>
      <div class="part3">
        <div>
          <span>万科城润园户型</span>
          <a href="">二居(1)</a>
          <a href="">三居(4)</a>
          <a href="">四居(3)</a>
          <a href="">更多>></a>
        </div>
        <div>这里是每个part里面的具体内容</div>
      </div>
    </div>
  </div>
</template>

其中我省略了大部分的细节实现，实际代码量应该是这里的数倍。

这段代码有几个问题：

  • 1.part1，2，3 的结构很类似，有些许重复

  • 2.实际的代码量将会很多，很难快速定位问题，维护难度较大

4.3 化繁为简

首先我们可以将 part1，2，3 进行分离，这样就独立出来三个文件，那么结构上将会非常清晰


<template>
  <div id="app">
    <div class="nav-search">...</div>
    <div class="panel">
      <part1 />
      <part2 />
      <part3 />
  </div>
</template>

这有些类似将一个大函数逐步拆解成几部分的过程，不难想象 part1，2，3 中的代码，必然是适用性很差，确切的说只有这里能够引用。(但我看过很多项目的代码，就是这么干的，认为自己做了组件化，抽象还不错(@_@))

4.4 组件抽象

仔细观察 part1，2，3，正如我上面所说，它们其实是很相似的：都具有相同的外层 border 并附有 shadow，都具有抬头和显示更多，各自内容部分暂不细说的话，这三个完全就是一模一样。

如此，我们将具有高度相似的业务数据进行抽离，实现组件的抽象。

part.vue

<template>
  <div class="part">
    <div class="hearder">
      <span>{{ title }}</span>
      <a :href="linkForMore">{{ showMore || '更多>>' }}</a>
    </div>
    <slot name="content" />
  </div>
</template>

我们将 part 内可以抽象的数据都做成了 props，包括利用 slot 去做模版，同时showMore || '更多>>'也考虑到了 part1 的 link 名字和其他几个 part 不一致的情况。

这样一来 app.vue 就更加清晰化


<template>
  <div id="app">
    <div class="nav-search">...</div>
    <div class="panel">
      <part
        title="万科城润园楼盘动态"
        linkForMore="#1"
        showMore="更多动态>>"
      >
        <div slot="content">这里是part1里面的具体内容</div>
      </part>
      <part
        title="楼盘故事"
        linkForMore="#2"
      >
        <div slot="content">这里是part2里面的具体内容</div>
      </part>
      <part
        title="万科城润园户型"
        linkForMore="#3"
      >
        <div slot="content">这里是part3里面的具体内容</div>
      </part>
  </div>
</template>

这里有几点需要说明一下：

  • 1.三个 part 中部分 UI 差异应该在哪里定义？

比如三个 part 的宽度都不一样，并且 part1 和 part2 可能要需要进行浮动。

必须要记住，这种差异并不是组件本身的，<part />的设计本身应该是无浮动并且宽度占 100%的，至于占谁的 100%，那就取决于谁引用它，至于向左还是向右浮动，同样也取决于引用它的 container 需要自己去定义，在上面的代码中，app.vue就应该是<part />的 container，app 想要的是一个左浮动且宽度为 80%的 part（part1），右浮动且宽度为 20%的 part（part2）和一个宽度为 100%的 part（part3），但它们都是 part，所以应该由 app 来设置这些差异。

记住这一点，将给你的抽象和扩展但来事半功倍的效果。

  • 2.三个 part 中的数据差异应该在哪里定义？

比如 part3 中，其他的 part 只有一个类似更多>>的 link，但是它却有多个(一居，二居...)。

这里我推荐将这种差异体现在组件内部，设计方法也很多：

比如可以将 link 数组化为 links；

比如可以将更多>>看作是一个 default 的 link，而多余的部分则是用户自定义的特殊 link，这两者合并组成了 links。用户自定义的默认是没有的，需要引用组件时进行传入。

总之，只要有数据差异化，就应该结合组件本身和业务上下文将差异合理的消除在内部。

  • 3.注意组件内数据的命名方式

一个通用的，可扩展性高的组件，必然是有非常合理的命名的，比如观察一些组件库的命名，总会出现类似list,data,content,name,key,callback,className等名词，绝对不会出现我们系统中的类似iterationList, projectName等业务名词，这些名词和任一产品和应用都无关，它与自身抽象的组件有关，只表明组件内部的数据含义，偶尔也会代表其结构，所以只有这样，才能让用户通用。

我们在组件化时，也需要遵循这种设计原则，但库往往是想让广大开发者通用，而我们可以降低 scope，做到在整个 app 内通用即可。所以从这个角度来说，好的组件化必然有好的 BA 和 UX，这是大实话

5.写在最后

你也许会认为这样抽象没有太大的必要性，毕竟它只是一段静态 UI（pure component），但任何的设计都是基于一定的复杂度才衍生出来的，其实大部分情况下这种设计都是需要将功能逻辑代码也纳入其中的，并不光只是 UI（如 antd, element-ui 等），我这里举的例子也相对比较简单，并不想有太多的代码。

个人认为在一个大型前端项目中，这种组件化的抽象设计是很重要的，不仅增加了复用性提高了工作效率，从某种程度上来说也反应了程序员对业务和产品设计的理解，一旦有问题或者需要功能扩展时，你就会发现之前的设计是多么的make sense（毕竟需求总是在变哪）。