组件化——前端编程的选择

一、前端为什么要做组件化

在大型软件系统中，web应用的前后端已经实现了分离，而随着REST软件架构的发展，后端服务逐步倾向于微服务，简单来说就是将一个大型后端服务，拆分成多个小服务，它们分别部署，降低了开发的复杂性，而且提高了系统的可伸缩性。而前端方面，随着技术的发展，开发的复杂度也越来越高，传统开发模式总是存在着开发效率低，维护成本高等的弊端。

传统开发方式效率低以及维护成本高的主要原因在于很多时候是将一个系统做成了整块应用，而且往往随着业务的增长或者变更，系统的复杂度会呈现指数级的增长，经常出现的情况就是一个小小的改动或者一个小功能的增加可能会引起整体逻辑的修改，造成牵一发而动全身。

针对此弊端，其实业界早就有了一些探索，我们希望一个大且复杂的场景能够被分解成几个小的部分，这些小的部分彼此之间互不干扰，可以单独开发，单独维护，而且他们之间可以随意的进行组合。就拿电脑主机来说，一台整机包括CPU，主板，内存，硬盘等等，而这些部件其实都是由不同的公司进行生产的，他们彼此之间根据一套标准分别生产，最后组装在一起。当某个部件出现问题时，不需要将整台主机都进行维修，只需要将坏的部件拿下来，维修之后再将其组合上就可以了。这种化繁为简的思想在后端开发中的体现是微服务，而在前端开发中的体现就是组件化。

随着React，angular等以组件（指令等）为主的优秀前端框架的出现，前端组件化逐渐成为前端开发的迫切需求，当然这一迫切需求也逐渐成为一种主流，一种共识，它不仅提高了前端的开发效率，同时也降低了维护成本。开发者们不需要再面对一堆复杂且难阅读的代码，转而只需要关注以组件方式存在的代码片段。

那么前端组件化开发都经历了哪些阶段呢？

二、 前端组件化开发发展之路

1、交互少的静态页面时期：公共模块和CSS

这是一个很古老的时代，那时的前端页面就是一些基本的HTML标签以及JS和CSS，页面上大部分都是一些静态的文字，就在这个时期，前端JS和CSS已经出现了组件化，或许更多的应该成为模块化，即开发者把不同模块的或者公共的JS和CSS放在不同的文件中，然后在页面引入并使用，这种方式也沿用至今。

2、繁琐的早期动态页面时期：动态引入

由于静态页面不能在页面上存储数据，阅读者也不满足于基本的页面交互，更希望页面能够活起来，且能够把交互的数据存储起来，于是出现了很多服务端技术，比如ASP，JSP。这些技术的出现使得前端页面活起来了，用户可以根据自己的需求进行数据的交互。

然而这时的页面上充斥着业务逻辑，随着业务逻辑的增多，页面的内容也越来越多，越来越复杂。在这个时期前端组件化开发得到了一定的发展，开发者已经不满足于简单的将JS和CSS文件模块化，开始把一些公用的页面逻辑独立开来，然后通过页面动态引入的方式进行使用，比如公共的页面头(header)和尾(footer)以及数据库的连接(DatabaseConn.jsp)等。

3、后端为主的MVC时期：Tag标签

由于早期动态页面时期的业务逻辑都写在页面上，随着逻辑的增多，页面越来越复杂，维护起来也越来越难。于是以servlet为代表的MVC时代逐渐登上历史舞台，这时页面上的逻辑都被转入到servlet中，使得View层的表现更加简洁，也更加的易于阅读，从而达到了开发的分层。

而随着Struts以及Spring的出现，MVC的开发方式达到鼎盛时期，前端View层的展现也变得越来越简单，没有了复杂的业务逻辑，前端的组件化方式主要是taglib标签，比如jsp标签，Struts标签等，把HTML代码和业务逻辑打包成一个标签，然后使用者直接放置在想要的地方，就可以了。但这个时期，整个WEB应用的开发轻前端重后端，那些taglib标签也都是JAVA代码编写的。

4、前端Ajax时期：JS大行其道

由于MVC时期的轻前端重后端的思想，前端页面主要以表格的形式展现，如果想要一些很炫的效果，实现起来就比较复杂了，往往要写一大堆的代码，而且很难阅读。AJAX作为早已经出现的技术在这个时候越来越受到开发者的青睐，于是出现了很多的JS框架，比如JQuery-UI， easy-UI，miniUI以及大名鼎鼎的ExtJS。

这些JS框架的出现使得前端组件化的开发到达了一个新的高度，利用封装Dom，AJAX以及页面交互的方式，一个个的很炫的组件出现了，开发者可以随意的将这些组件应用的页面中，开发变得简单的同时页面也变得越来越好看。由于这些交互都由JS来完成，运行在浏览器端，也大大的减少了服务端的压力，同时也提高了性能。

5、前端MV*时期：自定义组件

随着时间的推移，开发者发现，如果想要修改这些（ExtJS，miniUI）JS框架中的组件是非常困难的，因此开发者希望能够很容易的自定义一些组件。这时以Angular，React为代表的可以自定义组件的JS框架出现了。这些框架的出现不仅可以让开发者自定义组件，而且可以让开发者将已经存在的组件进行封装。

不仅如此，由于有了npm以及bower这些包管理库，开发者可以很容易的将自己开发的组件publish到这些库中，在使用时只要把他们下载下来（比如npm install）就可以直接使用了。比如：

以上的组件化基本以HTML和JS为主，那么CSS怎么做组件化呢？

6、CSS组件化：less和sass

前面讲了CSS的模块化基本上是将实现某一模块Dom样式的CSS放在不同的文件中，显然随着WEB应用的发展，开发者已经很不满足于这种简单的模块化了。 其实关于CSS的组件化，业界也早就已经有了很多探索，比如less，sass等。那么为什么CSS也要组件化呢？ 

我们知道CSS是一种扁平的结构，一个Dom可能对应着一个CSS样式，而这些CSS样式很有可能出现公共的部分，那么提取这些公共的部分也就实现了CSS的组件化，在诸如less和sass出现之前，开发者都是把公共的CSS样式写成一个个公共class，但是这样之后CSS文件的阅读性就变得困难了，当然也不容易修改。而less和sass出现之后，使得CSS的编程可以定义变量，可以实现继承，CSS内容的结构也变得更加清晰，提高了CSS文件的阅读性，更容易让人理解，修改起来也变得简单。

三、前端组件化的4个原则

前面讲了组件化开发的发展过程，那么我们该怎么做组件化呢？我认为组件应该遵守以下几个原则：

• 标准性

  任何一个组件都应该遵守一套标准，可以使得不同区域的开发人员据此标准开发出一套标准统一的组件。

  
  

• 组合性

  组件之前应该是可以组合的。我们知道前端页面的展示都是一些HTML DOM的组合，而组件在最终形态上也可以理解为一个个的HTML片段。那么组成一个完整的界面展示，肯定是要依赖不同组件之间的组合，嵌套以及通信。

  
  

• 重用性

  任何一个组件应该都是一个可以独立的个体，可以使其应用在不同的场景中。

  
  

• 可维护性

  任何一个组件应该都具有一套自己的完整的稳定的功能，仅包含自身的，与其它组件无关的逻辑，使其更加的容易理解，使其更加的容易理解，同时大大减少发生bug的几率。

四、总结与实践

当然组件化开发也并不是这么简单就能实践的。

• 对开发者的能力有一定的要求，比如传统开发方式可能只要求开发者懂HTML，JS，CSS这些就可以了，而组件化开发方式下还可能要求开发者掌握less，sass，或者ES6等的语法，以及webpack，glup等的前端打包以及构建工具。不过另一方面，哪个开发者不希望自己能掌握更多的本领呢？

  
  

• 技术选型，当前前端组件化框架可以说是百家齐放，这就要求技术经理或者架构师具有超前的前瞻性，根据项目需求以及框架的未来发展进行分析选型。

以我们公司目前在做的项目《普元数字化企业云平台》为例，整个前端项目由上海和西安两地的同事共4个人合作开发，在开发之初就确立了要采用一套统一的标准以减少异地开发的沟通成本，以及维护成本，显然组件化开发可以很好的满足此要求。

基于此，我们的前端使用的是Facebook的React技术，React的核心是使用组件定义界面的表现，它突出的就是开发组件化。 如下图所示，界面上的任何表现都对应着组件。组件之间很好的遵守了组件化开发的几个原则，不同区域的同事开发出的组件都如同同一个人写的，大大降低了异地的沟通成本和维护成本，以及提升了开发效率。

组件化开发方式对比传统开发方式：