前端能力中台化之路———— Fusion Design 成长史

摘要：快速摧毁敌军设施，杀伤有敌军生力量，最小化己方伤亡。所以前端工程师在修改完样式以后，需要反复和设计师还原度的问题。前端工程师依照主题包和设计稿进行前端工程开发。前端工程师很开心，因为不用去投入开发组件库和调整还原度。

作者: 暮尘

2019年05月11日在上海举办 FDCON 2019。笔者有幸受到邀请，参与这次盛会。这篇文章就是演讲内容的文字提炼版。

在开始正文内容之前，先简单聊聊“中台”这个词。 首要要说的是“中台”这个词中台非常火，从去年下半年到现在，互联网届多家知名大公司都公布组织架构调整，纷纷表示要建立各种中台。 另一方面，“中台”这个词暂时还没有一个很学术很权威的定义。笔者在知网搜索“中台”，前8页都没有看到任何一家商学院或者经管学院发表和“中台”有关的论文。 所以这里只能基于笔者自己的理解简单聊聊“中台”。

一线战斗人员 :“xxx位置发现敌人，请求火力支援。”

指挥部: “收到， 无人机出动”

紧接着，敌军所在的楼就被炸平了。

前端能力中台化萌芽

其实隐约有点中台化的味道。但是现在遍地开花的各种组件库能够满足多变的业务方诉求吗？答案是否定的。问题的核心点在于业务方对于视觉样式的多样性要求。

那么在这样的现状下，问题的解法有两种选择

独立维护: 视觉样式和业界各种库的差异都太大，所以维护一套专属组件库

定制现有: 找到业界一个六七成相似的库，修改它的默认样式

定制现有这种方式看起来省时省力，可是实际操作起来体验却不那么尽如人意。举两个例子。

所以独立维护和定制现有各有优缺点，并没有任何一方出现压倒性优势。最后就出现内部组件库遍地开花，技术栈林立，技术沉淀难以复用。

当时其实在中台思想的指导下，有些组件库的开发者就尝试把组件能力进一步透出，使得“定制现有“这条路更好走，让业务方不用把开发资源投入到基础组件库的开发上来。 这个最初的想法就是Fusion Design 起点。

为了解决多业务多样式的问题，我们自己独立维护了一套组件库 Fusion Next。然后为这套组件库打造了一个配置平台。二者结合就是一个组件库工厂，可以生产出各种样式的组件库。 具体效果如视频所示:

由于掘金不能播放视频,故把视频链接放在这: alifd.alicdn.com/assets/fdco…

实现Fusion Next & 样式配置平台的核心技术点有三个。

变量抽取

规则实现

动态渲染 接下来一一讲述。

变量抽取

变量抽取就是决定一个组件哪些量是可以配置，那些量不可以配置，可以配置的量抽离出来。这部分是Fusion Design开发过程中投入人力最大的一个点。 变量抽取的新核心理论是原子设计理论。

一个简单的Button就可以拆分成茫茫多的变量。而正是这么多的变量财能够满足业务方多变的视觉样式要求。最终50+组件梳理出3500+可配置量。

规则实现

上文中梳理出的3500+变量及其组件的配置规则。得益于前端领域成熟的 CSS预处理语言，这些变量和规则可以容易的落地为SASS/LESS变量。虽然这是一个很重要的技术点，但是难度并不大。这里不细说了，具体见Fusion Next Github

动态渲染

刚刚如果看了视频的同学可以看到，当组件的配置项的值被修改了以后，页面上组件状态也是跟着动态变化。其核心的一点就是服务端SASS编译。

当用户修改了某个变量，被修改的配置项会数据会被发送到服务端。

在服务端编译成为可用的 CSS，再返回到浏览器。

浏览器收到CSS数据之后，找到承载样式的style标签。

把其中的内容替换为刚获取的CSS。

就达到了动态渲染的效果。但是这个方案是 3 年前确定方案。随着浏览器原生能力的增强。CSS Variable 特性已经具有的较好的兼容性。CSS Variable 配合 一个存在许久API calc() 可以达到一样的效果。而且省去通信时间和服务器编译时间。这个方案是配置平台未来的演进方向。

主题包

配置平台的数据日常是沉淀在数据库中，为了方便前端工程师在开发中使用。用户完成配置以后， 配置平台会发布一个主题包，他是一个合法的npm包。包内既有元数据的沉淀: SASS/LESS/Javascript，方便SASS/LESS/CSS in JS 体系使用;也提供生产可用的CSS文件。

工作流

在完成配置平台之后，前端工程师也设计师协作的工作流程如下图所示。设计师在配置平台修改组件样式，产出主题包。前端工程师依照主题包和设计稿进行前端工程开发。

FusionCool的诞生

新的问题

在完成Fusion Next + 配置平台体系之后，逐渐开始接入实际的项目中使用。前端工程师很开心，因为不用去投入开发组件库和调整还原度。可是业务方的设计师用的不开心了。凭空增加他们的工作量却没有帮他们提效。

下图是设计领域很受欢迎的软件 Sketch。左边是默认样式的设计素材，一般由组件开发团队对外提供。右边是修改过样式后的组件。虽然在配置平台可以很方便的调整组件样式。可是在Sketch中，设计师要把左边样式的 Button 调整为橙色圆角 Button ，至少需要3个步骤。一个组件都已经如此麻烦。Fusion Next 内置50+组件。设计师的工作量之大可想而知。

FusionCool

上述问题的核心在于，设计素材并没有根据配置平台的数据而修改自身样式的。使得设计师在配置平台修改完样式还要到Sketch中再做一遍相同的工作。所以 Fusion 团队又开发一款Sketch插件。

由于掘金不能播放视频,故把视频链接放在这: alifd.alicdn.com/assets/fdco…

FusionCool 1.0

在接到FusionCool的需求时，最自然的想法就是 基于Fusion Next库，直接把 DOM节点转换为图片文件。设计软件对于图片文件是有天然的亲和性。而且DOM节点截图技术已经十分成熟。

这个想法很快遭到了否决， 主要是因为两条理由

图片文件生成后编辑其中的内容比较困难

jpg/png 放大失真

图片文件里面有一种比较特殊格式文件——SVG。SVG 和 HTML 都是类XML语言，转换方便。纯文本格式方便编辑。所以基于这条技术路线完成了 FusionCool 1.0。最终还原度大概在95%。对于业务方，特别是有像素眼的设计师，是不能接受这样”低“的还原度。所以这里就不赘述技术细节。

FusionCool 2.0

95%的还原度不能接受，但是至少比没有好。一边 FusionCool 1.0 踉踉跄跄的运行， 将就着使用。另一边 Fusion 团队在寻找新的技术方案。然后爱彼迎开源的一个库 React Sketch.app。这个库最初的目的是期望设计师能够通过写简单的React代码管理Sketch中的设计系统。在知乎上也有热烈的讨论如何评价 Airbnb 发布的 React Sketch.app 工具？。

这个库最初的梦想，我们这里暂时不去深究。最关键的一点是 React Sketch.app 指明了一条道路: React 代码可以直接渲染到 Sketch 中。经过评估，基于现有的Fusion Next再维护一套可渲染到Sketch的组件库成本并不是特别大。所以我们基于Fusion Next开发了一套库Sketch Next。目前我们正在做的工作是两件事:

Fusion Next和Sketch Next两个库做代码融合， 使得一个库就可以同时渲染到浏览器和Sketch两个端。

组件规范沉淀，使得业务方自己开发的组件也可以活动相同的能力。

在 React Sketch.app 技术的加持下，Fusion Next做到了99.9%的还原度。

无障碍

现在有了组件库， 也有了Sketch 插件，Fusion Design就能够做到”设计前端两开花，艺术工程双提效“。 然而，过了不久业务方又找过来了说: 业务收到了律师函警告，求援助。我心里犯嘀咕: 你们难道在站点上放人家唱、跳、Rap、打篮球的视频了");

相关法律

对于网页无障碍，各个国家和地区都有相应的法律法规做出要求。如果网站没做无障碍适配工作，是有法律风险。

为了解决业务方无障碍法律风险，Fusion团队从组件库底层开始接入无障碍能力。 并且在这个基础上做了3件事情。

能力内置

全球范围内， Web无障碍最权威的技术指导是W3C组织发布的 WCAG。目前 WCAG最新的版本是2.1。 Fusion Next根据 WCAG 2.1的指导，内置无障碍适配。 下图中左边是Fusion Next Select 组件，右边是Select组件渲染出来的HTML，可以看到HTMl标签上多了一些不常见的”aria-“标签。这些标签都是根据WCAG的要求生成，方便读屏软件识别其中内容。

WCAG并不只是对于代码层面有要求，对于网页的设计也是有要求。FusionDesign在设计方面完成了适配工作。

举个例子: 视障人群并不是完全看不见， 具体见盲人的世界到底是一片黑色，还是连黑色也不存在？。多数其实能看到色彩，只是模模糊糊。所以对于网页的色彩，hover态、disable态的颜色就要和普通状态的颜色对比度差异够大，才能便于视障用户感知他们的区别。所以配置平台在修改品牌色的面板中，增加了颜色对比度标识，方便设计师更好的选择颜色。

权威合作

Fusion 团队还和无障碍领域的权威研究机构————浙江大学中国残疾人信息和无障碍技术研究中心(后文简称浙大无障碍中心)进行了深度合作。 浙大无障碍中心权威在哪里呢");

产出指引

WCAG 2.1是最权威的指导，但是他更像是一个需求列表，前端工程师直接去阅读，还是有一些理解成本和实践成本。Fusion团队基于自己的理解和实践， 编撰并对外发布《Fusion Web无障碍开发指引》。这份开发指引，针对前端工程师编写，更容易理解和上手。

在经过业务方的接入增多，业务复杂性增加。Fusion Desgin也在不断丰富自身的能力，中台自身能力强大了，才能给业务提供强有力的火力支援。

目前内部服务 40+ 业务方， 2000+项目。

去年12月，Fusion Design对外开源开放。目前对外版FusionCool日活1500+，发布7600+主题包。

横向拓展，即从服务设计师和前端的协同，扩展到其他协作领域。

纵向深入————设计稿生成代码

在设计师和前端的协同领域深挖， 目前设计稿转代码都是通过AI去”猜测“设计稿上某个组件是那种组件，它对应的代码是什么。但是如果设计师是通过FusionCool辅助创作设计稿，那么FusionCool是可以知道设计稿上的组件是对应的那个组件以及其对应的代码。 那么在AI+FusionCool两条腿都走路的情况下，期望能够在设计稿生成代码领域做出新的突破。

一分钟广告 官网 & Github仓库

官网: fusion.design Github: github.com/alibaba-fus…