Element：一套通用组件库的开发之路
Element 是由饿了么UED设计、饿了么大前端开发的一套基于 Vue 2.0 的桌面端组件库。今天我们要分享的就是开发 Element 的一些心得。
官网：
http://element.eleme.io/#/github：
https://github.com/ElemeFE/element## 设计目的
大部分项目起源都是源于业务方的需求，Element 也是一样。随着公司业务发展，内部开始衍生出很多后台系统，UED 部门也接到越来越多的设计需求，分析整个过程，我们发现如下问题：
- 日渐增多的后台产品设计需求
- 设计资源有限，没办法支持所有业务线
- 公司内部诸多后台产品使用体验不一致
于是我们决定：
- 设计一套后台支撑框架，提升后台系统的可用性和一致性
- 套用此框架，即使没有设计师参与，也能让产品或开发设计出一套好用的后台系统
## 设计阶段
下面简单说一下设计 Element 经历的几个阶段。
**了解业务并熟悉公司内各后台产品，寻找业务上的共性问题**
设计的目的是为了业务服务。第一步我们从内部系统开始入手，了解公司内部在使用的各种后台系统，将其组件抽象剥离，寻找共性特征。
**专注业务组件设计**
总结了公司不同系统不同组件的使用情况后，我们打算从业务组件入手，因为这部份是由公司特殊需求衍生的解决方案，我们认为解决了这些棘手的问题，也能给其他后台产品带来好的设计引导。
**寻求开发支持**
到这一步，我们开始寻找公司内部的开发团队，并在这时才得知不同团队里使用着不同的前端框架，有 Vue、React、Angular 等等。
**与大前端合作**
大前端作为独立的前端团队，有能力开发底层的工具去服务不同业务，并且 Vue 也是一套年轻且发展方向很好的一个技术栈。UED 与大前端的合作一拍即合。
**方向转变，专注于基础组件**
跟大前端接触后，才发现最开始的方向并不正确，因为业务变化过快，即使有通用的业务组件，也很难跟上需求的变化，而基础组件才是所有开发团队都需要的通用组件。这时候我们开始把方向调整为基础组件的设计。
**组件交互完成，进行视觉封装，并搭建主体网站**
前期的设计工作主要是由交互设计师进行设计，等确认完所有组件的功能和交互后，开始进行视觉阶段，这中间包括制定颜色、字体等各类规范，也同时进行主体网站的设计。
输出 UI Kit 文件，统一设计规范
第一版网站设计，此处的「特殊组件」即业务组件。
**网站二次设计**
第一版网站上线后视觉效果并不好，我们内部进行了调整，再次上线后就是大家现在看到的样子。
设计过程简单来说就经历了这几个阶段，如还有问题可以继续交流，下面进入开发阶段。
## 开发目的
- 后台系统缺乏一套完整的基础组件库
- Vue 在公司内部是一个比较年轻的技术栈，希望做一些基础设施的建设
- 提升公司在技术社区的影响力
## 开发流程
进入开发阶段后，在总体架构方面我们做了一些尝试，下面按照时间顺序分享给大家：
**如何与设计师进行配合**
经过项目初期开发和设计的磨合，我们提炼了一套组件开发流程：
1. 根据交互稿和视觉稿进行开发，期间与设计师保持沟通
2. 开发完成后自测，之后提交设计师验收
3. 设计师提出修改意见，根据意见进行修改
4. 完成组件开发，为网站编写例子和文档
**如何管理多组件项目**
在开发之初，我们就在思考如何降低组件的耦合度，确保组件可以独立工作。这样的目的是可以保证组件可以依赖其他组件、让用户只加载其中几个组件甚至在安装时只安装需要的组件。最先想到的做法是一个组件单独一个仓库，而组件库项目就是把组件作为依赖引入。
但是由于人手不足，这样的机制导致开发太耗时间，每个组件都需要单独维护和打包，同时还要维护组件库项目的各依赖的版本号。我们只能另寻方案。后来参考了
[babel](
https://github.com/babel/babel) 项目的管理方式：所有子项目放在 `packages/`
目录里，一个子项目可以当作一个独立的仓库。通过 [lerna](
https://github.com/lerna/lerna)
来管理子项目的依赖和发布。
结合自身项目的特点以及 babel 的这套机制，我们重构了目录结构：组件可单独作为一个项目放在 `packages/`，共用函数放在
`src/` 里。最后的打包结果会将整个组件打包成一个文件、组件分别打包成独立文件，同时发布时还将发布组件库和独立组件，满足不同用户的使用需求。
**如何解决自定义主题**
开发一套组件库就离不开定制主题的需求。类名要足够友好，尽量避免存在样式层级嵌套，这样在直接覆盖样式或者单独写一套主题都会方便许多。所以我们采用 BEM 的方式管理类名，同时尽可能将属性值用变量代替，维护一份变量文件便于直接修改变量就能定制一套主题。
考虑到不同用户的使用习惯，我们没有选用 Less 或 Sass 之类的有各自风格的预处理器，而是选用了更接近未来标准的 CSS4
风格的语法，用 PostCSS 和整合了 postcss-bem 和 postcss-cssnext 等插件的
[postcss-salad](
https://github.com/ElemeFE/postcss-salad) 开发。
为了降低用户自定义主题的上手成本，我们还提供了命令行工具指导用户快速自定义一套主题。
**如何提供一份直观的文档**
文档不仅是让用户看起来直观，也要让编写者写起来直观。所以最简单的方式是用 Markdown
写文档。但是就会产生另一个问题：如何在文档里写可运行的示例？常规的做法是把文档写在 Vue
文件里，这样就可以在里面调用其他组件，但是这样就违背了写「直观」文档的初衷。
经过几番尝试，结合 Vue 的特点。我们写了一套处理 Markdown 文件的 webpack loader，可以将 Markdown 转成 Vue 文件，不仅降低了文档的维护成本，同时也将文档里运行组件示例变成可能。
**多语言官网如何配置和管理**
Element 在立项之初其实并没有考虑国际化的问题。项目开源之后，我们陆续收到了一些外国开发者的反馈，希望能够增加英文文档。不久之后，国内的一个翻译团队主动联系到了我们，为 Element 贡献了整套英文文档。
有了英文文档就需要有英文网站，这就需要对官网的现有结构进行修改和升级；同时为了面向未来，需要官网能够兼容除英语外的其他多语言。为此我们做了以下工作：
1. 路由
官网的路由是根据一个记录了导航信息的 `json` 文件自动生成的。因此需要在这个 `json` 文件中添加对应于其他语言的字段，并且根据新的数据结构修改路由生成的逻辑。
2. 页面
官网中除了文档外，还有一些介绍性质的页面。这些页面中文字比较多，如果人工管理每种语言的页面，若需要修改则必须去每个页面相应的位置进行编辑，有些繁琐。我们的做法是：每个页面对应一个模板，模板中的文字全部抽取到一个语言配置文件中，并且写了一个脚本生成最终的页面。这样在需要修改时，只需在语言配置文件中编辑对应的字段即可。
3. 网站组件
对于 `header` 、`footer` 等通用的页面组件，我们采取了和上面类似的策略。但由于组件内的文字较少，于是没有再使用模板，而是通过路由判断应该显示何种语言。
中英文网站的显示效果
至此，我们也逐渐完善了技术栈。用 ES2015 和 CSS4 作开发语言、Lerna 负责管理组件、用 Karma 搭配 Mocha 和
Chai 等工具在 Travis CI 里做持续集成测试，最后用 Markdown 结合 Vue 写文档。我们甚至还在 CI
里实现了自动部署网站和推送主题仓库代码等功能，提升了不少开发效率。