饿吗？基于Vue2.0的通用组件开发之路

Element是一个基于Vue 2.0的桌面组件库，由饿了么UED设计，饿了么大前端开发。今天要分享的是一些开发Element的经验。

官网:/ElemeFE/element

# #设计目的

大多数项目源于业务方的需求，Element也是如此。随着公司业务的发展，内部衍生了很多后端系统，UED部门也收到了越来越多的设计需求。在分析了整个过程后，我们发现了以下问题:

-对背景产品设计的需求日益增加。

-有限的设计资源，无法支持所有业务线

-公司很多后台产品体验不一致。

所以我们决定:

-设计一套后台支撑框架，提高后台系统的可用性和一致性。

-应用这个框架，即使没有设计师的参与，也能为产品或开发设计出一套有用的后台系统。

# #设计阶段

下面简单说一下设计一个元素的几个阶段。

* *在公司了解业务熟悉后台产品，在业务中寻找* * *性问题* *

设计的目的是为企业服务。第一步，从内部系统入手，了解公司使用的各种后端系统，抽象剥离其组件，寻找* * * *的特点。

* *专注于业务组件设计* *

在总结了公司不同系统的不同组件的用法后，我们打算从业务组件入手，因为这部分是源于公司特殊需求的解决方案，我们认为解决这些棘手的问题也能给其他后台产品带来很好的设计指导。

* *寻求发展支持* *

此时，我们开始在公司内部寻找开发团队，然后我们了解到不同的团队使用不同的前端框架，包括Vue、React、Angular等等。

* *使用大型前端* *

大前端作为一个独立的前端团队，有能力开发底层工具服务于不同的业务，Vue也是一个年轻且发展良好的技术栈。UED和大前端的合作一拍即合。

* *改变方向，专注于基本组件* *

和大前端接触后，发现最初的方向并不正确，因为业务变化太快，即使有通用的业务组件，也很难跟上需求的变化，基础组件是所有开发团队需要的通用组件。这时，我们开始把方向调整到基础部件的设计上。

* *组件交互完成，进行可视化包装，搭建主网站* *

前期设计工作主要由交互设计师设计。在确认了所有组件的功能和交互后，视觉阶段开始，包括制定颜色、字体等各种规格，同时设计主网站。

输出UI套件文件，统一设计规范。

在第一版网站设计中，这里的“特殊组件”就是业务组件。

* *网站重新设计* *

网站第一版上线后，视觉效果不好，我们进行了内部调整。再次上线后，就是现在大家看到的样子。

简而言之，设计过程经历了这些阶段。如果还有问题，可以继续交流。让我们进入发展阶段。

# #开发目的

-后台系统缺乏一套完整的基础组件库

-Vue是公司里比较年轻的技术栈，想做一些基础设施建设。

-提升公司在技术社区的影响力。

# #开发流程

进入开发阶段后，我们在整体架构上做了一些尝试。让我们按时间顺序与你分享:

* *如何与设计师合作* *

在项目的初始开发和设计之后，我们改进了一套组件开发流程:

1.根据交互稿和视觉稿进行开发，期间保持与设计师的沟通。

2.开发后自检，然后提交给设计师验收。

3.设计人提出修改意见，并根据意见进行修改。

4.完成组件开发，并为网站编写示例和文档。

* *如何管理多组件项目* *

开发之初，我们就在思考如何降低组件的耦合度，保证组件能够独立工作。这样做的目的是保证组件可以依赖其他组件，让用户只加载其中的少数几个，甚至在安装时只安装需要的组件。首先想到的是，一个组件是一个独立的仓库，组件库项目就是引入组件作为依赖。

但是由于人力不足，这种机制的开发太耗时，每个组件都需要单独维护和打包，同时维护组件库项目的依赖版本号。只能另找方案了。后来提到

[babel](/babel/babel)项目管理模式:所有子项目都放在` packages/'中。

在目录中，子项目可以视为一个独立的仓库。经由[lerna](/lerna/lerna)

管理子项目的依赖关系和发布。

结合我们自己项目的特点和babel的这种机制，我们重构了目录结构:组件可以作为单个项目放在' packages/'中，而* * *可以放在函数中。

` src/`li。最终的打包结果会把整个组件打包成一个文件，组件分别打包成独立的文件。同时，还将发布组件库和独立组件，以满足不同用户的需求。

* *如何解决自定义主题* *

开发一个组件库离不开自定义主题的需求。类名要足够友好，尽量避免样式级嵌套，这样直接覆盖样式或者单独写一组主题会方便很多。所以我们用BEM来管理类名，同时尽可能用变量代替属性值。我们可以通过维护一个变量文件来定制一组主题，以便可以直接修改变量。

考虑到不同用户的使用习惯，我们选择了更接近未来标准的CSS4，而不是Less或Sass等自有风格的预处理器。

样式语法，使用PostCSS并集成了postcss-bem和postcss-cssnext等插件。

[post CSS-salad](/eleme Fe/post CSS-salad)开发。

为了降低用户自定义主题的成本，我们还提供了命令行工具来指导用户快速自定义一组主题。

* *如何提供直观的文档* *

文档不仅让用户看起来直观，也让作者写起来直观。最简单的方法是使用Markdown。

写文档。但另一个问题会出现:如何在文档中写出可操作的例子？传统的做法是用Vue编写文档。

文件，以便可以调用其中的其他组件，但这违背了编写“直观”文档的初衷。

经过几次尝试，结合Vue的特点。我们编写了一套webpack loader来处理Markdown文件，可以将Markdown转换成Vue文件，不仅降低了文档的维护成本，还使得在文档中运行组件实例成为可能。

* *如何配置和管理多语言官方网站* *

Element在项目之初并没有真正考虑国际化。项目开源后，我们收到了一些国外开发者的反馈，希望增加英文文档。不久之后，国内的一个翻译团队主动联系我们，向Element贡献了一整套英文文档。

如果你有英文文档，你需要一个英文网站，这就需要对官网现有结构进行修改和升级。同时，为了面向未来，官网需要兼容除英语之外的其他语言。为此，我们做了以下工作:

1.按指定路线发送

官网的路线是根据一个记录导航信息的json文件自动生成的。因此，需要在这个json文件中添加对应于其他语言的字段，并根据新的数据结构修改路由生成的逻辑。

2.页

除了文档，官网还有一些介绍页面。这几页里有很多单词。如果手动管理每种语言的页面，需要修改就必须到每个页面对应的位置进行编辑，有些繁琐。我们的做法是:每个页面对应一个模板，将模板中的所有单词提取到一个语言配置文件中，编写一个脚本，生成最终的页面。这样，当你需要修改它时，你只需要在语言配置文件中编辑相应的字段。

3.网站组件

对于常见的页面组件，如“页眉”和“页脚”，我们采用与上面类似的策略。但是由于组件中缺少文本，所以不再使用模板，而是通过路由判断应该显示的语言。

中英文网站的显示效果

在这一点上，我们已经逐步完善了技术栈。ES2015和CSS4作为开发语言，Lerna负责管理组件，Karma配合Mocha和。

Chai等工具在Travis CI中做持续集成测试，最后用Markdown结合Vue写文档。我们甚至在CI

在这个系统中，实现了自动部署网站、推送主题仓库代码等功能，提高了很多开发效率。