大规模的前端组件化与模块化

本文根据 Andrew Betts 在 QCon 北京 2014 大会上的主题演讲内容整理而成。

Andrew Betts 是英国金融时报实验室（FT Labs）的负责人，同时也是一位 PHP 和 JavaScript 程序员。他的团队致力于研发试验性质的 Web 技术并发布相关产品——比如金融时报 Web App. 在加入金融时报实验室之前，Andrew 创建了 Web 咨询公司 Assanka，为诸如 News International, The Economist Group and the FT 这样的客户打造创新性的 Web 项目。

今天的话题是大规模的前端组件化与模块化。首先，先介绍一下 FT 在研发方面面临的挑战：

不同的服务如搜索、内容、广告、应用，都是由不同的团队来开发，团队之间的沟通较少。造成的结果就是，整个服务的灵活性和可维护性越来越差，系统变得越来越复杂之后，新人进来的学习难度很大。随着整个软件开发生命周期变得越来越复杂，新功能的集成变得越来越难；更糟糕的是，随着移动设备的流行，研发团队不得不把同样一套逻辑分别在桌面端和移动端各自实现一次。这也是全世界的软件研发团队面对的挑战。

为了应对这些问题，FT Labs 开始推行几条前端的开发理念，目前已经获得比较好的效果。

第一条理念是：“活的”风格指南。“活的”风格指南也可以理解为代码即文档，文档即示例。这里举一个例子，比如 Facebook 的 React 项目。你去看 React 项目的介绍页，这个页面本身就是一个 React 的推荐实现。

当然像 React 这样的项目，说明页面的实现是一个方面，此外还有另一个重点：组件化的开发方式。正如 React 不是一个框架——它提倡的是无框架，因为任何框架的引入都会增加额外的复杂度和学习成本。组件（Web components）则不同，它一旦开发出来，就是一个随时可以很方便的调用的功能；而且，不同的团队可以同时进行不同组件的开发而互不干扰。Web 组件是一个正在快速发展中的特性，目前浏览器对它的支持还不完美，不过也就是 1-2 年的时间，现在应该要为未来做准备。对于 Web 开发而言，向前兼容要比向后兼容更加重要。

组件化的使用在我们处理历史网站的过程中节省了大量的工作。FT 有超过 600 个域名需要维护，很多网页从互联网时代早期就开始运作。对于这些遗留页面，要全都重写以适应新的浏览器是代价高昂、不值得的，但你又要尽可能的让它们能够正常显示。我们用组件来进行局部替换以解决这个问题。比如某个老页面上有一个图库展示，现在的浏览器不能显示了，你就批量把这种老旧的图库展示代码替换成新的图库组件代码即可。

另外还有一点很重要，就是拥抱模块化，避免在代码中嵌入依赖关系。做开发这行儿一个很重要的觉悟就是：你要相信，你现在写出来的这些代码，等两年之后，你自己都会不想去看它。模块化会让你的生命更简单。

对于浏览器兼容性，正如刚才所说，我们的建议是跟着最新的浏览器功能走。不过这里面也有一个分界点，就是所谓 core experience 和 primary experience 的分界点，并尽可能的将分界点向扩大 core experience 的方向推进。对于 NoJavaScript 的处理，我们的经验是，基本上所有人的浏览器都会支持 JS 的，尽可以放心大胆的用。

说到这里，我要进入今天的重头了，那就是 FT 的 Origami 这个项目。Origami 这个项目要做定义的话可以说是一套规范，是一组文档化的最佳实践，同时搭配 Registry 这套工具，以方便所有人以最佳实践建立规范统一的服务和组件。

这套系统的构成大体上包括一套 closure compiler，browserfy（+debowerfy&brfs），commonjs，sass（用于做 css 模块化），taskrunner（基于 grunt），以及 bower。系统在设计上遵循几个原则：

• 编译时纳入所有依赖
• 去中心化、分布式，比如我们的 git repo 是分散的，没有一个所谓的 core 或 common 的 codebase
• 内置命名和封装的规则

对于上面提到的分界点，Origami 是这样处理的：core 的部分需要保证在用户环境对 JavaScript 支持差或不支持的情况仍然能够完成基本内容的呈现、搜索引擎的抓取等。这个分界点在 Origami 当中通过 if (querySelector in document) 来实现判定。

Registry 作为工具，会做以下几个事情：

• 扫描所有已知的 git 服务器
• 给版本标签建索引
• 给每个模块的每个版本做 build
• 把每个模块的所有版本收集、整理到一个模块页面上

Registry 可以说是我们 Web 服务的一个黄页。我们把这个黄页放在公开的互联网上，这样所有人都可以上去协作，每个人都可以查看每个组件的每个版本，它们的说明和相关文档，实现的样板等。如果有的功能还没做完或者没启用，可以打上一个 not implemented 的 flag。

大家可以在 Registry 上随意查看我们的各个组件，比如 header，footer，调色板，按钮等。这些组件调用起来很简单，以调色板为例，只需要

 
<link rel="stylesheet" href="http://build.origami.ft.com/bundles/css?modules=o-colors@^2.3.8" /> 
<script src="http://build.origami.ft.com/bundles/js?modules=o-colors@^2.3.8"'></script> 

这样的两行代码即可调用任意模块的任意版本。

我们的 build 服务可以按需 build 不同模块的任意组合，之后还进行打包、压缩、优化等处理并通过 CDN 分发（经过了 GZIP 处理）。调用的时候可以指定调用指定的版本，或者自动调用最新版。有了这套系统后，开发者创建原型变得非常简单了。

下面我介绍一下我们遇到的一些零碎问题，以及我们是如何处理的。

首先，有关 polyfill 的加载，如何才能让 polyfill 仅在需要的时候才加载？我们的处理办法是在模块的 metadata 中进行声明，哪些是 required，哪些是 optional，以 modernizr 测试名来进行控制。

然后，如何在支持 JS 但是支持的不好的浏览器中显示 noscript 当中的内容？我们的办法是定义一个 o-nojs-fallback 类的 div，通过类的 visibility 来控制呈现。

对于 hover 的处理，我们用了一个 o-hoverable 的组件来控制。

对于资源加载，为了确保每个组件都知道其他资源的 URL 地址，我们专门有一个 o-asset 组件。

最后想说的是，将我们的这些工作公开在互联网上，我们从中收获了很多。