基本思路

1. 为什么要做组件化？

无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。

减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Linux + Mono来部署.net应用，避开Windows Server的费用。

提高开发效率这方面，业界研究得更多，主要途径有两点：加快开发速度，减少变更代价。怎样才能加快开发速度呢？如果我们的开发不是重新造轮子，而是 每一次做新产品都可以利用已有的东西，那就会好很多。怎样才能减少变更代价呢？如果我们能够理清模块之间的关系，合理分层，每次变更只需要修改其中某个部 分，甚至不需要修改代码，仅仅是改变配置就可以，那就更好了。 我们先不看软件行业，来看一下制造行业，比如汽车制造业，他们是怎么造汽车的呢？造汽车之前，先设计，把整个汽车分解为不同部件，比如轮子，引擎，车门， 座椅等等，分别生产，最后再组装，所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了，需要送去维修，维修的人也没有在每个地方都修一下，而是只把轮胎 拆下来修修就好了，这个轮胎要是实在坏得厉害，就干脆换上个新的，整个过程不需要很多时间。

席德梅尔出过一款很不错的游戏，叫做《文明》（Civilization），在第三代里面，有一项科技研究成功之后，会让工人工作效率加倍，这项科技的名字就叫做：可替换部件（Replacement Parts）。所以，软件行业也应当引入可替换的部件，一般称为组件。

2. 早期的前端怎么做组件化的？

在服务端，我们有很多组件化的途径，像J2EE的Beans就是一种。组件建造完成之后，需要引入一些机制来让它们可配置，比如说，工作流引擎，规 则引擎，这些引擎用配置的方式组织最基础的组件，把它们串联为业务流程。不管使用什么技术、什么语言，服务端的组件化思路基本没有本质差别，大家是有共识 的，具体会有服务、流程、规则、模型等几个层次。

早期展示层基本以静态为主，服务端把界面生成好，浏览器去拿来展示，所以这个时期，有代码控制的东西几乎全在服务端，有分层的，也有不分的。如果做了分层，大致结构就是下图这样：

这个图里，JSP（或者其他什么P，为了举例方便，本文中相关的服务端技术都用Java系的来表示）响应浏览器端的请求，把HTML生成出来，跟相 关的JavaScript和CSS一起拿出去展示。注意这里的关键，浏览器端对界面的形态和相关业务逻辑基本都没有控制权，属于别人给什么就展示什么，想 要什么要先提申请的尴尬局面。

这个时期的Web开发，前端的逻辑是基本可忽略的，所以前端组件化方式大同小异，无论是ASP还是JSP还是其他什么P，都可以自定义标签，把HTML代码和行间逻辑打包成一个标签，然后使用者直接放置在想要的地方，就可以了。

在这一时代，所谓的组件化，基本都是taglib这样的思路，把某一块界面包括它的业务逻辑一起打成一个端到端的组件，整个非常独立，直接一大块从界面到逻辑都有，而且逻辑基本上都是在服务端控制，大致结构如下图所示。

3. SPA时代，出现了新问题

自从Web2.0逐渐流行，Web前端已经不再是纯展示了，它逐渐把以前在C/S里面做的一些东西做到B/S里面来，比如说Google和微软的在线Office，这种复杂度的Web应用如果还用传统那种方式做组件化，很显然是行不通的。

我们看看之前这种组件化的方式，本质是什么？是展现层跟业务逻辑层的隔离，后端在处理业务逻辑，前端纯展现。如果现在还这么划分，就变成了前端有界 面和逻辑，后端也有逻辑，这就比较乱了。我们知道，纯逻辑的分层组件化还是比较容易的，任何逻辑如果跟展现混起来，就比较麻烦了，所以我们要把分层的点往 前推，推到也能把单独的展现层剥离出来。

如下图所示，因为实际上HTML、CSS、JavaScript这些都逐渐静态化，所以不再需要把它们放在应用服务器上了，我们可以把它们放在专门 的高性能静态服务器上，再进一步发展，就可以是CDN（Content Delivery Network，内容分发网络）。前端跟后端的通信，基本都是通过AJAX来，也会有一些其他的比如WebSocket之类，总之尽量少刷新了。

在这张图里面可以看到，真正的前端已经形成了，它跟应用服务器之间形成了天然的隔离，所以也能够很独立地进行一些发展演进。

现在很多Web程序在往SPA（单页面程序，Single Page Application）的方向发展，这类系统通常比较类似传统的C/S程序，交互过程比较复杂，因此它的开发过程也会遇到一些困难。

那为什么大家要做SPA呢？它有很多明显的好处，最核心的优势就是高效。这个高效体现在两个方面：一是对于用户来说，这种方式做出来的东西体验较 好，类似传统桌面程序，对于那些需要频繁操作的行业用户，有很大优势。二是运行的效率较高，之前集成一些菜单功能，可能要用iframe的方式引入，但每 个iframe要独立引入一些公共文件，服务器文件传输的压力较大，还要初始化自己的一套内存环境，比较浪费，互相之间也不太方便通信，一般要通过 postMessage之类的方式去交互。

有了SPA之后，比如一块界面，就可以是一个HTML片段，用AJAX去加载过来处理之后放到界面上。如果有逻辑的JavaScript代码，也可以用require之类的异步加载机制去运行时加载，整体的思路是比较好的。

很多人说，就以这样的需求，用jQuery再加一个异步js加载框架，不是很足够了吗？这两个东西用得好的话，也是能够解决一些问题的，但它们处理 的并不是最关键的事情。在Web体系中，展现层是很天然的，因为就是HTML和CSS，如果只从文件隔离的角度，也可以做出一种划分的方式，逻辑放在单独 的js文件里，html内部尽量不写js，这就是之前比较主流的前端代码划分方式。

刚才我们提到，SPA开发的过程中会遇到一些困难，这些困难是因为复杂度大为提升，导致了一些问题，有人把这些困难归结为纯界面的复杂度，比如说， 控件更复杂了之类，没有这么简单。问题在于什么呢？我打个比方：我们在电脑上开两个资源管理器窗口，浏览到同一个目录，在一个目录里把某个文件删了，你猜 猜另外一个里面会不会刷新？

毫无疑问，也会刷新，但是你看看你用的Web页面，如果把整个复杂系统整合成单页的，能保证对一个数据的更新就实时反馈到所有用它的地方吗？怎么做，是不是很头疼？代码组织的复杂度大为提高，所以需要做一些架构方面的提升。

4. 架构的变更

提到架构，我们通常会往设计模式上想。在著名的《设计模式》一书中，刚开始就讲了一种典型的处理客户端开发的场景，那就是MVC。

传统的MVC理念我们并不陌生，因为有Struts，所以在Web领域也有比较经典的MVC架构，这里面的V，就负责了整个前端的渲染，而且是服务端的渲染，也就是输出HTML。如下图所示：

在SPA时代，这已经不合适了，所以浏览器端形成了自己的MVC等层次，这里的V已经变成客户端渲染了，通常会使用一些客户端的HTML模版去实现，而模型和控制器，也相应地在浏览器端形成了。

我们有很多这个层面的框架，比如Backbone，Knockout，Avalon，Angular等，采用了不同的设计思想，有的是MVC，有的是MVP，有的是MVVM，各有其特点。

以Angular为例，它推荐使用双向绑定去实现视图和模型的关联，这么一来，如果不同视图绑定在同一模型上，就解决了刚才所说的问题。而模型本身也通过某种机制，跟其他的逻辑模块进行协作。

这种方式就是依赖注入。依赖注入的核心理念就是通过配置来实例化所依赖的组件。使用这种模式来设计软件架构，会牺牲一些性能，在跟踪调试的便利性等方面也会有所损失，但换来的是无与伦比的松耦合和可替代性。

比如说，这些组件就可以单独测试，然后在用的时候随手引入，毫无压力。对于从事某一领域的企业来说，光这一条就足以吸引他在上面大量投入，把所有不常变动领域模型的业务代码都用此类办法维护起来，这是一种财富。

5. MV*框架的基本原理

如果我们来设计Angular这么一个前端框架，应当如何入手呢？很显然，逻辑的控制必须使用JavaScript，一个框架，最本质的事情在于它的逻辑处理方式。

我们的界面为什么可以多姿多彩？因为有HTML和CSS，注意到这两种东西都是配置式的写法，参照后端的依赖注入，如果把这两者视为跟Spring框架中一些XML等同的配置文件，思路就豁然开朗了。

与后端不同的是，充当前端逻辑工具的JavaScript不能做入口，必须挂在HTML里才能运行，所以出现了一个怪异的状况：逻辑要先挂在配置文 件（HTML）上，先由另外的容器（浏览器或者Hybird的壳）把配置文件加载起来，然后才能从某个入口开始执行逻辑。好消息是，过了这一步，逻辑层就 开始大放异彩了。

从这个时候开始，框架就启动了，它要做哪些事情呢？

• 初始化自身（bootstrap）
• 异步加载可能尚未引入的JavaScript代码（require）
• 解析定义在HTML上的规则（template parser）
• 实例化模型（scope）
• 创建模型和DOM的关联关系（binding, injection）

这些是主线流程，还有一些支线，比如：

• 解析url的search字符串，恢复状态（route）
• 加载HTML部件模板（template url）
• 部件模板和模型的关联（binding）

6. 如何做组件化

6.1. HTML的组件化

SPA的一个典型特征就是部分加载，界面的部件化也是其中比较重要的一环。界面片段在动态请求得到之后，借助模版引擎之类的技术，经过某种转换，放置到主界面相应的地方。所以，从这个角度来看，HTML的组件化非常容易理解，那就是界面的片段化和模板化。

6.2. JavaScript的组件化

JavaScript这个部分有好几个发展阶段。

• 早期的共享文件，把公共功能的代码提出出来，多个页面共用
• 动态引用，消灭全局变量
• 在某些框架上进一步划分，比如Angular里面又分为provider，service，factory，controller

JavaScript组件化的目标是什么呢，是清晰的职责，松耦合，便于单元测试和重复利用。这里的松耦合不仅体现在js代码之间，也体现在js跟 DOM之间的关系，所以像Angular这样的框架会有directive的概念，把DOM操作限制到这类代码中，其他任何js代码不操作DOM。

如上图所示，总的原则是先分层次，层内再作切分。这么做的话，不再存在之前那种端到端组件了，使用起来没有原先那么方便，但在另外很多方面比较好。

6.3. CSS的组件化

这方面，业界也有很多探索，比如LESS，SASS，Stylus等。为什么CSS也要做组件化呢？传统的CSS是一种扁平的文本结构，变更成本较 高，比如说想要把结构从松散改紧凑，需要改动很多。如果把实际使用的CSS只当作输出结果，而另外有一种适合变更的方式当作中间过程，这就好多了。比如 说，我们把一些东西定义成变量，每个细节元素使用这些变量，当需要整体变更的时候，只需修改这些变量然后重新生成一下就可以了。

以上，我们讨论了大致的Web前端开发的组件化思路，后续将阐述组件化之后的协作过程和管控机制。

1. 什么是前端工程化

自有前端工程师这个称谓以来，前端的发展可谓是日新月异。相比较已经非常成熟的其他领域，前端虽是后起之秀，但其野蛮生长是其他领域不能比的。虽然前端技术飞快发展，但是前端整体的工程生态并没有同步跟进。目前绝大多数的前端团队仍然使用非常原始的“切图（FE）->套模板（RD）”的开发模式，这种模式下的前端开发虽说不是刀耕火种的原始状态，但是效率非常低下。

前端的工程化问题与传统的软件工程虽然有所不同，但是面临的问题是一样的。我们首先回顾一下传统的软件开发流程模型：

上图中的运行和维护并不是串行关系，也并非绝对的并行关系。维护贯穿从编码到运行的整个流程。

如果说计算机科学要解决的是系统的某个具体问题，或者更通俗点说是面向编码的，那么工程化要解决的是如何提高整个系统生产效率。所以，与其说软件工程是一门科学，不如说它更偏向于管理学和方法论。

软件工程是个很宽泛的话题，每个人都有自己的理解。以上是笔者个人的理解，仅供参考。

具体到前端工程化，面临的问题是如何提高编码->测试->维护阶段的生产效率。

可能会有人认为应该包括需求分析和设计阶段，上图展示的软件开发模型中，这两个阶段具体到前端开发领域，更恰当的称谓应该是功能需求分析和UI设计，分别由产品经理和UI工程师完成。至于API需求分析和API设计，应该包括在编码阶段。

2. 前端工程化面临的问题

要解决前端工程化的问题，可以从两个角度入手：开发和部署。

从开发角度，要解决的问题包括：

1. 提高开发生产效率；
2. 降低维护难度。

这两个问题的解决方案有两点：

1. 制定开发规范，提高团队协作能力；
2. 分治。软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治。

从部署角度，要解决的问题主要是资源管理，包括：

1. 代码审查；
2. 压缩打包；
3. 增量更新；
4. 单元测试；

要解决上述问题，需要引入构建/编译阶段。

2.1 开发规范

开发规范的目的是统一团队成员的编码规范，便于团队协作和代码维护。开发规范没有统一的标准，每个团队可以建立自己的一套规范体系。

值得一提的是JavaScript的开发规范，尤其是在ES2015越来越普及的局面下，保持良好的编码风格是非常必要的。笔者推荐Airbnb的eslint规范。

2.2 模块/组件化开发

2.2.1 模块还是组件？

很多人会混淆模块化开发和组件化开发。但是严格来讲，组件（component）和模块（module）应该是两个不同的概念。两者的区别主要在颗粒度方面。《Documenting Software Architectures》一书中对于component和module的解释如下：

A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

简单讲，module侧重的是对属性的封装，重心是在设计和开发阶段，不关注runtime的逻辑。module是一个白盒；而component是一个可以独立部署的软件单元，面向的是runtime，侧重于产品的功能性。component是一个黑盒，内部的逻辑是不可见的。

用通俗的话讲，模块可以理解为零件，比如轮胎上的螺丝钉；而组件则是轮胎，是具备某项完整功能的一个整体。具体到前端领域，一个button是一个模块，一个包括多个button的nav是一个组件。

模块和组件的争论由来已久，甚至某些编程语言对两者的实现都模糊不清。前端领域也是如此，使用过bower的同行知道bower安装的第三方依赖目录是bower_component；而npm安装的目录是node_modules。也没必要为了这个争得头破血流，一个团队只要统一思想，保证开发效率就可以了。至于是命名为module还是component都无所谓。

笔者个人倾向组件黑盒、模块白盒这种思想。

模块化/组件化详情：链接

模块化

就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。在工程化之前，一直是使用js、jquery、ajax，这没有模块概念，对于开发大型且复杂的系统会有一定的限制。

组件化

首先，组件化≠模块化。好多人对这两个概念有些混淆。

模块化只是在文件层面上，对代码或资源的拆分；而组件化是在设计层面上，对UI（用户界面）的拆分。

从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元，我们称之为组件。

组件：页面是个大型组件，可以拆成若干个中型组件，然后中型组件还可以再拆，拆成若干个小型组件，小型组件也可以再拆，直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件，作为组件的基本单元。

传统前端框架/类库的思想是先组织DOM，然后把某些可复用的逻辑封装成组件来操作DOM，是DOM优先；而组件化框架/类库的思想是先来构思组件，然后用DOM这种基本单元结合相应逻辑来实现组件，是组件优先。这是两者本质的区别。

2.2.2 模块/组件化开发的必要性

随着web应用规模越来越大，模块/组件化开发的需求就显得越来越迫切。模块/组件化开发的核心思想是分治，主要针对的是开发和维护阶段。

关于组件化开发的讨论和实践，业界有很多同行做了非常详细的介绍，本文的重点并非关注组件化开发的详细方案，便不再赘述了。笔者收集了一些资料可供参考：

1. Web应用的组件化开发；
2. 前端组件化开发实践;
3. 大规模的前端组件化与模块化。

3. 构建&编译

严谨地讲，构建（build）和编译（compile）是完全不一样的两个概念。两者的颗粒度不同，compile面对的是单文件的编译，build是建立在compile的基础上，对全部文件进行编译。在很多Java IDE中还有另外一个概念：make。make也是建立在compile的基础上，但是只会编译有改动的文件，以提高生产效率。本文不探讨build、compile、make的深层运行机制，下文所述的前段工程化中构建&编译阶段简称为构建阶段。

3.1 构建在前端工程中的角色

在讨论具体如何组织构建任务之前，我们首先探讨一下在整个前端工程系统中，构建阶段扮演的是什么角色。

首先，我们看看目前这个时间点（2016年），一个典型的web前后端协作模式是什么样的。请看下图：

上图是一个比较成熟的前后端协作体系。当然，目前由于Node.js的流行开始普及大前端的概念，稍后会讲述。

自Node.js问世以来，前端圈子一直传播着一个词：颠覆。前端工程师要借助Node.js颠覆以往的web开发模式，简单说就是用Node.js取代php、ruby、python等语言搭建web server，在这个颠覆运动中，JavaScript是前端工程师的信心源泉。我们不讨论Node.js与php们的对比，只在可行性这个角度来讲，大前端这个方向吸引越来越多的前端工程师。

其实大前端也可以理解为全栈工程师，全栈的概念与编程语言没有相关性，核心的竞争力是对整个web产品从前到后的理解和掌握。

那么在大前端模式下，构建又是扮演什么角色呢？请看下图：

大前端体系下，前端开发人员掌握着Node.js搭建的web server层。与上文提到的常规前端开发体系下相比，省略了mock server的角色，但是构建在大前端体系下的作用并没有发生改变。也就是说，不论是大前端还是“小”前端，构建阶段在两种模式下的作用完全一致，构建的作用就是对静态资源以及模板进行处理，换句话说：构建的核心是资源管理。

3.2 资源管理要做什么？

前端的资源可以分为静态资源和模板。模板对静态资源是引用关系，两者相辅相成，构建过程中需要对两种资源使用不同的构建策略。

目前仍然有大多数公司将模板交由后端开发人员控制，前端人员写好demo交给后端程序员“套模板”。这种协作模式效率是非常低的，模板层交由前端开发人员负责能够很大程度上提高工作效率。

3.2.1 静态资源构建策略

静态资源包括js、css、图片等文件，目前随着一些新规范和css预编译器的普及，通常开发阶段的静态资源是：

1. es6/7规范的文件；
2. less/sass等文件（具体看团队技术选型）；
3. [可选]独立的小图标，在构建阶段使用工具处理成spirit图片。

构建阶段在处理这些静态文件时，基本的功能应包括：

1. es6/7转译，比如babel；
2. 将less/sass编译成css；
3. spirit图片生成；

以上提到的几个功能可以说是为了弥补浏览器自身功能的缺陷，也可以理解为面向语言本身的，我们可以将这些功能统称为预编译。

除了语言本身，静态资源的构建处理还需要考虑web应用的性能因素。比如开发阶段使用组件化开发模式，每个组件有独立的js/css/图片等文件，如果不做处理每个文件独立上线的话，无疑会增加http请求的数量，从而影响web应用的性能表现。针对诸如此类的问题，构建阶段需要包括以下功能：

1. 依赖打包。分析文件依赖关系，将同步依赖的的文件打包在一起，减少http请求数量；
2. 资源嵌入。比如小于10KB的图片编译为base64格式嵌入文档，减少一次http请求；
3. 文件压缩。减小文件体积；
4. hash指纹。通过给文件名加入hash指纹，以应对浏览器缓存引起的静态资源更新问题；
5. 代码审查。避免上线文件的低级错误；

以上几个功能除了压缩是完全自动化的，其他两个功能都需要人工的配置。比如为了提升首屏渲染性能，开发人员在开发阶段需要尽量减少同步依赖文件的数量。

以上提到的所有功能可以理解为工具层面的构建功能。

以上提到的构建功能只是构建工具的基本功能。如果停留在这个阶段，那么也算是个及格的构建工具了，但也仅仅停留在工具层面。对比目前较流行的一些构建产品，比如fis，它具备以上所得的编译功能，同时提供了一些机制以提高开发阶段的生产效率。包括：

1. 文件监听。配合动态构建、浏览器自动刷新等功能，提高开发效率；
2. mock server。并非所有前端团队都是大前端（事实上很少团队是大前端），即使在大前端体系下，mock server的存在也是很有必要的；

 我们也可以将上面提到的功能理解为平台层面的构建功能。

3.2.2 模板的构建策略

模板与静态资源是容器-模块关系。模板直接引用静态资源，经过构建后，静态资源的改动有以下几点：

1. url改变。开发环境与线上环境的url肯定是不同的，不同类型的资源甚至根据项目的CDN策略放在不同的服务器上；
2. 文件名改变。静态资源经过构建之后，文件名被加上hash指纹，内容的改动导致hash指纹的改变。

其实url包括文件名的改动，之所以将两者分开论述是为了让读者区分CDN与构建对资源的不同影响。

对于模板的构建宗旨是在静态资源url和文件名改变后，同步更新模板中资源的引用地址。

现在有种论调是脱离模板的依赖，html由客户端模板引擎渲染，简单说就是文档内容由JavaScript生成，服务端模板只提供一个空壳子和基础的静态资源引用。这种模式越来越普遍，一些较成熟的框架也驱动了这个模式的发展，比如React、Vue等。但目前大多数web产品为了提高首屏的性能表现，仍然无法脱离对服务端渲染的依赖。所以对模板的构建处理仍然很有必要性。

具体的构建策略根据每个团队的情况有所差异，比如有些团队中模板由后端工程师负责，这种模式下fis的资源映射表机制是非常好的解决方案。本文不讨论具体的构建策略，后续文章会详细讲述。

模板的构建是工具层面的功能。

3.2.3 小结

构建可以分为工具层面和平台层面的功能：

• 工具层面

1. 预编译，包括es6/7语法转译、css预编译器处理、spirit图片生成；
2. 依赖打包；
3. 资源嵌入；
4. 文件压缩；
5. hash指纹；
6. 代码审查；
7. 模板构建。

• 平台层面

1. 文件监听，动态编译；
2. mock server。

4. 总结

一个完整的前端工程体系应该包括：

1. 统一的开发规范；
2. 组件化开发；
3. 构建流程。

开发规范和组件化开发面向的开发阶段，宗旨是提高团队协作能力，提高开发效率并降低维护成本。

构建工具和平台解决了web产品一系列的工程问题，旨在提高web产品的性能表现，提高开发效率。

随着Node.js的流行，对于前端的定义越来越宽泛，在整个web开发体系中。前端工程师的角色越来越重要。本文论述的前端工程体系没有涉及Node.js这一层面，当一个团队步入大前端时代，前端的定义已经不仅仅是“前端”了，我想Web工程师这个称号更合适一些。

之前跟一位前端架构师讨论构建中对于模块化的处理时，他提到一个很有意思的观点：所谓的压缩打包等为了性能做出的构建，其实是受限于客户端本身。试想，如果未来的浏览器支持大规模并发请求、网络延迟小到微不足道，我们还需要压缩打包吗？

诚然，任何架构也好，策略也好，都是对当前的一种解决方案，并不是一条条铁律。脱离了时代，任何技术讨论都没有意义。

参考文献：链接

自从 2010 年第一份工作接触了前后端半分离的开发方式之后，在后面的这些年里，对前端的组件化开发有了更全面一点的认识，组件化在我们的前端开发中，对提高开发效率、代码的可维护性和可复用性有很大帮助，甚至对跟设计师沟通的效率和企业的品牌形象都有着深刻的影响。这篇文章就把我在开发中总结的一些组件化开发经验分享一下。示例中的所有代码都是伪代码，你可以按照实际情况应用到 React 或 Vue 的项目中。

前端组件化发展历史

在讨论组件化开发之前，我们先看看前端组件化开发的发展历史。网页开发刚起步时，并没有『前端』这个概念，更不用提组件化了。当时，网页只是作为可以在浏览器中浏览的富文本文件，开发网页就是使用一些标签让浏览器解析并显示。受制于 HTML 只是描述式的语言，网页中的代码没有办法复用，即使是类似的页面，都需要复制粘贴大量的重复代码：

<!-- index.html -->
<nav>
  <!-- 导航 -->
</nav>
<main>
  <!-- 内容 -->
</main>
<footer>
  <!-- 页脚 -->
</footer>

<!-- blogPost.html -->
<nav>
  <!-- 相同的导航 -->
</nav>
<main>
  <!-- 不同的内容 -->
</main>
<footer>
  <!-- 相同的页脚 -->
</footer>

后来随着模板引擎的出现，可以把网页的代码分割成片段（Fragments）或模板（Templates），例如导航，内容，页脚等等，之后在需要的地方，使用引入（Include）语法，把这些片段引入进来，从而避免重复代码，这样形成了组件化的雏形，常见的动态脚本语言都有自己的模板引擎，例如 PHP、ASP 和 JSP：

<!-- nav.jsp -->
<nav>
  <!-- 导航 -->
</nav>

<!-- index.jsp -->
<jsp:include page="nav.jsp" />

只是这些片段在数据管理方面仍然会比较麻烦，还是需要使用客户端 JavaScript 脚本，手动控制数据和 HTML 视图的同步。而对于样式，也还是存在全局污染的问题。
再后来，有些高级的开发语言，例如 Java， 推出了基于服务器的组件化开发技术，例如 JSF （JSP 的后继），基于 MVC 设计模式，通过 Java Class (POJO) 定义数据模型（Model），为 JSF 页面模板提供数据。JSF 的数据模型中有事件和生命周期相关的方法，而模板和数据模型通信的方式是 Ajax，通过使用 JSF facelets 组件的方式，可以直接发送 Ajax 请求，调用模型中的方法：

<!-- index.xhtml -->
<html
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:h="http://xmlns.jcp.org/jsf/html"
  xmlns:f="http://xmlns.jcp.org/jsf/core"
>
  <h:commandButton id="submit" value="Submit">
    <f:ajax event="click" />
  </h:commandButton>
  <h:outputText id="result" value="#{userNumberBean.response}" />
</html>

// UserNumberBean.java
@Named
@RequestScoped
public class UserNumberBean implements Serializable {
	/* 其它代码省略 */

    public String getResponse() {
        if ((userNumber != null)
                && (userNumber.compareTo(dukesNumberBean.getRandomInt()) == 0)) {
            return "Yay! You got it!";
        }
        if (userNumber == null) {
            return null;
        } else {
            return "Sorry, " + userNumber + " is incorrect.";
        }
    }
}

代码来源：Jarkarta EE 官方示例
不过这种方式严格限定了编程语言，例如要用 JSF 技术就必须要使用 Java，并且样式污染的问题和客户端数据管理的问题仍然没有解决。
随着 Node.js 的普及，JavaScript 可以脱离浏览器运行了，并且带来了 npm 包管理器，基于 npm 庞大的工具链，可以 Node.js 的代码打包成浏览器中能够运行的代码。而这期间，产生了像 React、Vue 和 Angular 这样的、适合大型前端项目开发的库和框架。

React 和 Vue 目前的流行程度比较高一些，它们都是纯客户端的、组件化的 JS 库，不依赖任何后端编程语言，让程序员都能够快速上手。不过，随着项目规模的扩大，如何利用好这些库进行组件化开发，成了前端工程师必须要掌握的课题。

什么是组件

那么到底什么是组件呢？你想一下日常生活中，电脑上的硬件，例如显卡、内存、CPU，或者汽车的零部件：轮胎、发动机、方向盘等，这些都属于组件，它们组合起来能形成一个完整可用的产品，对于遵循了设计规范的组件，只要型号匹配，无论品牌、样式，都可以互相兼容。
我们前端工程师其实就当于是一个工厂，我们需要按照一定的规范，产生出合格的网页组件，利用它们组装成完整的页面。组件一般包含 HTML 模板、CSS 样式和 JavaScript 数据逻辑，自成一体，可以直接在其它组件中使用，组件本身的模板、样式和数据不会影响到其它组件。组件还包含一系列可配置的属性，动态的产生内容。

常见的基础组件有按钮、导航、提示框、表单输入控件、对话框、表格、列表等，我们在它们的基础上又能组合出更复杂的组件，那么对于前端中的组件的定义就非常广泛了，小到一个按钮，大到一个页面都可以形成一个组件，例如两个相似的页面，可以复用一个页面组件，只需要通过修改组件的属性，来形成一个新的页面。

为什么要组件化开发

你可能也知道，React 和 Vue 其实也可以完全按照传统的网页开发方式进行开发，最多是把网页大体分成几个部分，放到单独的几个文件里就好了，对于简单的网站来说没什么问题，但是如果开发的是大型的应用，例如网页版的 QQ 音乐、微信、邮箱等，它们有大量的、细小的组件，并且重复出现，这时如果针对每个页面编写 HTML 和样式，那么就会造成太多冗余代码了。

<!-- playlist.html -->
<div class="card">
  <div class="card__title"></div>
  <div class="card_content"></div>
</div>

<!-- homepage.html -->
<div class="card">
  <div class="card__title"></div>
  <div class="card_content"></div>
</div>

<!-- user.html -->
<div class="card">
  <div class="card__title"></div>
  <div class="card_content"></div>
</div>

如果使用组件化的方式，我们可以把重复出现的页面内容定义成组件，这样就不用复制粘贴同样的代码了，减少代码的体积：

<!-- 伪组件 -->
<!-- Card.comp -->
<div class="card">
  <div class="card__title"></div>
  <div class="card_content"></div>
</div>

<!-- playlist.html -->
<Card />

<!-- homepage.html -->
<Card />

<!-- user.html -->
<Card />

当某个页面内容是复合组件时，那么可以直接把基础组件直接拿过来应用：

<Card>
  <Title></Title>
  <Button></Button>
</Card>

利用这种方式，甚至可以达到 1 分钟产生一个新页面的恐怖速度，这对于你来说，节省时间去摸鱼，岂不美哉？

<Page title="页面1" data="{...}" /> <Page title="页面2" data="{...}" />

对于大型的公司来说，公司的网站、APP、桌面应用、Web 端应用等的设计风格都是一样的，同样的组件会在不同平台中使用，这个时候团队之间可以共享一套组件库，复用到各端平台上，减少重复开发的成本。React 和 Vue 都支持创建跨平台的应用，这时组件化开发就显得更重要了：

使用组件化开发之后，代码也容易维护了，如果页面某个部分出了问题，那么我们可以针对出现问题的组件进行修复，多次用到这个组件的地方也都会一起修复了。
最后，设计师在设计产品界面的时候，会把重复出现的 UI 也做成『组件』，这个组件的概念几乎和前端中的组件一模一样，这时可以跟设计师交流想法，看看他/她是怎么规划组件的，这样也减少了在开发时，设计规划组件的时间。
​

接下来分享一下我在组件化开发中总结的经验：

一、组件的规划

在正式进行前端应用开发之前，需要有充分的时间来分析，看看页面上的哪些内容需要做成组件。这一步只需要大致规划一下：

• 如果公司设计师提供了详细的设计规范，那么直接按照规范中的组件来开发就可以了。

• 如果只有设计稿，那么就看看哪些内容有 2 次或更多次在其它页面中用到了，这些大概率需要设计为组件。
• 如果连设计稿都没有，那么可以用市面上现成的组件库，例如 ant design。
• 如果没有设计稿，还要自己从零开发，那么可以根据通用的套路，把基础组件，例如按钮、菜单等，规划出来，并把可能会多次用到的页面内容，也规划出来，例如导航，底部信息、联系方式区域，这样可以只改动需要变化的部分，不影响其它部分。

这一步不用太过详细，浪费太多时间，后续开发的时候如果遇到不确定是否要写成组件的部分，可以直接把这部分代码写到大的组件里，如果其它组件又用到了，再把它抽离成组件。

二、组件代码管理

组件的代码应该遵循就近原则，也就是说：

• 和组件有关的 HTML、CSS 、JS 代码和图片等静态资源应该放在同一个目录下，方便引用。
• 组件里的代码应该只包括跟本组件相关的 HTML 模板、CSS 样式和 JS 数据逻辑。
• 所有的组件应放到一个统一的『组件文件夹中』。

如果组件之间有可以复用的 HTML 和 CSS，那么这个复用的部分可以直接定义成一个新的组件。

如果组件之间有可以复用的 JS 数据逻辑，那么可以把公用的数据逻辑抽离出来，放到公共的业务逻辑目录下，使用到该逻辑的组件，统一从这个目录中导入。

如果项目中使用到了全局状态管理，那么状态管理的数据应放在独立的目录里，这个目录还会存放分割好的状态片段 reducer，之后统一在 store 中合并。

对于项目中的** API 处理**，可以把它们单独放到一个文件夹里，对于同一个数据类型的操作，可以放到同一个 js 文件里，例如对 user 用户数据的增删改查，这样能尽最大可能进行复用，之后在组件里可以直接引入相关 api 进行调用。如果直接写在组件里，那么使用相同 API 的组件就会造成代码重复。
例如下面是一个组件化开发的目录结构示例（框架无关）：

project
|-- components                # 所有组件
      |-- Card                # Card 组件
          |-- index.js        # Card 组件 js 代码
          |-- Card.html       # Card 组件 html 模板
          |-- Card.css        # Card 组件 css 样式
          |-- icon.svg        # Card 组件用到的 icon
|-- logics                    # 公共业务逻辑
      |-- getUserInfo.js      # 例如获取用户信息
|-- data                      # 全局状态
      |-- store.js            # 全局状态管理 store
      |-- user.reducer.js     # user reducer
      |-- blogPost.reducer.js # blogPost reducer
|-- apis                      # 远程请求 API 业务逻辑
      |-- user.js             # user API
      |-- blogPost.js         # blogPost API

三、组件样式管理

在编写组件样式的时候，应只设置组件 CSS 盒子内部的样式，影响外部布局的样式要尽可能的避免，而应该由使用该组件的父组件去设置。例如，如果有一个组件设置了外边距，但是这个组件经常会用于 grid 或 flex 布局中，那么这个额外的边距会对布局造成影响，只能通过重置外边距的方式取消边距，这就不如组件不设置外边距，由父组件的布局决定它的位置，或者外边距。

类似的还有定位相关的样式，绝对定位、固定定位等对文档流有影响，应交由父组件决定，除非这个组件只有绝对定位这一种情况，例如对话框。
组件中的 CSS 要局部化，以避免影响全局样式。传统的 CSS 样式是全局的，如果有两个不同的组件，使用了相同的 class 名字，那么后定义的样式会覆盖之前定义的。一般前端库中都有定义局部样式的功能，例如通过 CSS Modules。

<!-- Vue -->
<style scoped></style>

<!-- React，通过文件名 -->
Button.module.css

修改子组件的样式时，优先使用选择器特异性（CSS Specificity）策略选定特定元素，而行内样式（inline-style）在设置简单样式的时候使用，尽一切可能避免 !important，因为如果再有上一层组件（爷爷组件）需要修改这个组件的样式时，就会很困难了。

四、组件属性管理

组件属性的命名要与它实际展示的内容相符。例如一个博客文章组件，title 属性表示标题，content 代表内容，showFullArticle 表示是否显示全文。

<!-- 不推荐，full 表示什么？ -->
<BlogPost title="" content="" full="" />
<!-- 推荐 -->
<BlogPost title="" content="" showFullArticle="" />

组件的属性应有必要的类型检查，避免在使用属性时出现异常，例如在需要数组的地方传递了布尔类型，那么如果代码有遍历数组的逻辑，就会出错。

props: {
	title: String,
  content: String,
  showFullArticle: Boolean
}

代表事件的属性，应该和现有的 HTML 事件名称规范保持一致，以 on 开头，后面用英文表示会触发的事件，例如 onEdit 表示会触发编辑事件。

<BlogPost onEdit="" />

组件的属性不能直接和状态进行捆绑，而是应该只作为状态的初始值。如果把属性值作为状态值，那么就破坏了单一数据流向机制，此时该组件可以通过自身修改状态，也能通过父组件的属性变化修改状态，很容易造成数据的不一致。推荐的做法是，设置一个初始值属性，可以通过父组件传递进来，当作状态的初始值，然后丢弃，后续只通过该组件修改状态值。

const { initialTitle } = props;
const title = state(initialTitle);

// 修改
updateTitle() {
 title = "...";
}

五、组件状态管理

组件的状态分为全局状态和局部状态两种。
局部状态是定义在组件本身的状态，应由组件本身内部管理，当子组件需要该组件的状态值时，通过属性传递给子组件，此时状态变化时，子组件也会自动刷新。

// 父组件
const someState = state("");

<ChildComponent prop1="someState"></ChildComponent>;

当子组件需要给父组件传递状态的值时，要通过事件的方式传递给父组件，尽最大可能避免使用 ref。

// 父组件
function getStateVal(val) {
  console.log(val);
}
<ChildComponent onChange="getStateVal" />

// 子组件
<input onChange="e => getStateVal(e.target.value)" />

状态的变化还应只通过事件或生命周期来进行，不能在其它同步执行的代码中进行，这样不会引起组件的刷新。

const someState = state();

// 错误
const state = "newState";

// 正确
handleButtonClick() {
  someState = "newState";
}

全局状态是多个组件共享的，如果有多个组件共享某个状态，那么应该把状态定义在这些组件统一的、最接近的父组件中，或者使用全局状态管理库。

全局状态的修改，应该由类似于 actions 的行为触发，然后使用 reducer 修改状态，这样能追溯状态的变化路径，方便调试和打印日志。

// 组件
function updateState() {
  emitAction("changeState");
}

// reducer
function someState(state, action) {
	switch(action) {
    "changeState": someState => {
      	log(someState);
    		return newState
    }
  }
}

全局状态推荐按领域（Domain）来拆分 reducer，而不是按页面。例如按 user 用户、文章 posts、评论 comments 来拆分，而不是以 HomePage 主页、BlogPostListPage 博客列表页，BlogPostPage 博客详情页这样来拆分。这样做的好处是，能够最大限度的复用 reducer 中的逻辑。

// userReducer

{
	"updateUser": ...
  "deleteUser": ...
  /* ... */
}

六、组件的组合

前端开发就是组合不同的组件。
在组合组件的时候，尽量使用『插槽』的形式（例如 React 的 children/render props，Vue 的 slot），这样可以减少组件的嵌套，避免多层传递属性或事件监听。
使用 slot：

// Layout 组件
<div>
  <!-- nav slot -->
  <!-- content slot -->
  <!-- footer slot -->
</div>

// 首页 function handleNavChange() {}

<Layout>
  <nav onChange="handleNavChange"></nav>
  <main></main>
  <footer></footer>
</Layout>

不使用 slot：

// Layout props: { onNavChange: function }
<Layout>
  <!-- 还需再传递一层 -->
  <nav onChange="onNavChange"></nav>
  <main></main>
  <footer></footer>
</Layout>

// 首页 function handleNavChange() {}
<Layout onNavChange="handleNavChange" />

如果有循环展示列表的地方，需要对循环中最外层的组件设置 key，这样在列表发生变化时，能帮助前端库判断是否可以通过排序的方式，重复利用现有的组件，来更新视图，而不是销毁重建。

let todos = [{id: 1, content: "todo1"}, {id:2, content: "todo2"}, {id:3,
content: "todo3"}];

<List>
  for todo in todos:
  <item content="todo.content" key="todo.id" />
</List>

// todos 顺序变化，列表也只是根据 id 调整顺序，不会销毁重建 todos = [{id: 3,
content: "todo3"}, {id:2, content: "todo2"}, {id:1, content: "todo1"}];

如果有按条件展示组件的地方，且切换频率高，或有动画需求，要使用设置 css display 的方式，例如 vue 中的 v-show，如果切换频率低，可以使用加载、销毁的方式，例如 vue 中的 v-if，React 中使用 && 逻辑判断。

七、组件的复用

在复用组件的时候，可以通过改变组件的属性来修改一些简单的组件内容。

<Card title="" content="<ContentComp />" />

如果组件结构类似，但是有些内部的组件不一样，可以考虑通过『插槽』来复用。

<!-- Comp -->
<div>
  <h1></h1>
  <!-- slot -->
</div>

<!-- 其它组件 -->
<Comp>
  <p>替换 slot</p>
</Comp>

如果有业务逻辑需要复用，尤其是涉及到状态变化的，那么可以把它抽离为公共的业务逻辑，利用 Hooks（React）或 Composables （Vue）来复用。

// 公共逻辑 (/logic/useSomeLogic.js)
function useSomeLogic() {
  const someState = state();
  const updateState = (v) => (someState = v);
  return {
    someState,
    updateState,
  };
}

// 组件1复用
import userSomeLoginc from "/logic/useSomeLogic.js";
const { someState, updateState } = useSomeLogic();

// 组件2复用
import userSomeLoginc from "/logic/useSomeLogic.js";
const { someState, updateState } = useSomeLogic();

如果有视图样式需要复用，那么可以直接把这部分再抽离成一个新的组件。

小结

这篇文章从组件的代码、样式、属性、状态、组合和复用的这几个场景上，总结了一些我在前端开发中的一些经验和个人看法，可能并不适用所有项目，如果你有更好的最佳实践和经验，欢迎分享！如果觉得本文有帮助，请分享给其它人，感谢！

原文地址：https://zxuqian.cn/7-ways-to-organize-frontend-components，欢迎访问查看更多前端开发教程！
Bilibili：峰华前端工程师
公众号：峰华前端工程师