阿里中后台UI解决方案 - Fusion

2018年12月16号，Fusion 在OSC 深圳源创会年终盛典上对外开源开放了, 这个在阿里内部跑了三年的产品，终于正式对外了。

可能一些业界的同学在这之前已经在某些渠道听说过阿里的 Fusion Design

距离上次对外发声，Fusion 在阿里内部又走了两年，这两年内我们技术领域又有了一些突破。这次重点介绍我们的突破吧。不过介绍前还是要说下 Fusion 是做什么的，毕竟还是有很多同学是第一次听说的！

一般一个专案的上线流程基本都要经历，评审、设计、开发、测试 这几个阶段。

而各个阶段又可以再深入进去的拆分，大致如下：

这里重点说下流程中的两个问题。

问题1： 重复工作

这里面标黄了的部分表示可能是各个业务线间的重复工作：

问题2： 协同问题

协同遇到的问题，上面知乎连结里面周源的回答已经非常清楚了，我这里再大概总结下。

那未来在Fusion 模组模板达到极度丰富后，使用可以方便的找到各个领域的模组模板来使用，不需要从0开始搭建。

一个平台：fusion.design

两个工具：1. 开发者工具 Iceworks 2. 设计师工具 FusionCool

建立自己的 Design System

每个人或者团队都可以通过 可以建立自己的站点

站点提供三种能力：文件编辑、主题管理、物料托管

主题配置管理

集成了可以管理、定制、释出元件的主题的能力（下文会简称为配置平台）

物料托管

可以使用开发好的区块、模板

2.2.1 设计师工具 - FusionCool

主题释出完成后就到了 Sketch 的外挂端 FusionCool，设计师可以在 FusionCool 里面搜寻 iconfont 所有素材、使用配置好的元件、使用站点的模组模板。

2.2.2 开发者工具 - Iceworks

Fusion Next 是基于 React 实现的一套 PC 端的元件库，这套元件库已经在阿里内部服务了三年。这次开源出来的版本是最近一年基于之前两年的使用经验、问题反馈进行重新整理和优化过。具备以下特性

易用性

对比上一个版本 80 + 功能，进行 300+ 优化，元件整体程式码体积却减小30%

一共 50+元件，打包下来却只有 700 多K，这个目前在业界比较少元件有能力做到这点。元件之间依赖关系清晰，复用度高也是体积小的原因。

稳定性

元件单测覆盖率近90%，提供服务以来没有产生过起线上事故。

能力增强

国际化、RTL、无障碍能力全面支援。

另外针对中后台表单大资料量场景做了大量效能优化，比如普通 table 随着资料不断增长 render 会越来越慢，大致如下：

Next 引入了 virtual-list ，目前用在了 table 和 select 这两个使用频率较高的元件。因为在大资料量(测试过1w节点）下只渲染需要展示的节点（比如20个），所以可以将渲染时长永远的控制在 0.3s 之内。

程式码到视觉稿的无损还原

早在一年前我们是把设计师在主题配置平台（直接在web页面配置元件的主题）的元件直接通过 html2svg 技术直接把元件直接转换为svg档案，从而让设计师可以直接在 sketch 里面使用。但是这种方案存在的弊端就是还原度不够（大概95%还原度）。

主要原因是 html 采用盒模型 和 svg 的转换并不是一一对应的，所以这里永远有修不完的bug。虽然95% 是好的，但是对于设计端来说是完全不能忍受的。

所以 Fusion 专案小组经过近半年的努力终于突破了还原度的问题，流程图如下

从配置平台汇出的不再是 html，而是 DesignToken （设计变数），FusionCool 底层使用 Airbnb 提供的 react-sketch 能力写成的一份 Next 元件，直接通过 DesignToken 覆盖预设变数，最终在 Sketch 端实时渲染。

sketch 端的任何点选都可以通过 Event 的方式在 FusionCool 产生配置面板。