vue结合饿了么_饿了么基于Vue2.0的通用组件开发之路（分享会记录）

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/` 里。最后的打包结果会将整个组件打包成一个文件、组件分别打包成独立文件，同时发布时还将发布组件库和独立组件&#x