背景
在阿里云，可能每时每刻都在身边充斥着“数据表”“模型”“调度”等等抽象概念。作为阿里云的前端，如何将这种形象的概念实体化可视化地给客户或者其余合作伙伴展现进去显得尤为重要。
与此同时，在阿里云智能事业部门的孵化速度和迭代速度大大超乎大家的设想，总结起来就是“人少事多繁琐”，经常出现拉1-2个同学两周内就开始孵化一个我的项目，此时，业界内各种搭建零碎能缓解一部分的工作量，可是当遇到了可视化“编排”，“流程图”，“关系图”这种场景，就显得顾此失彼了。
通过盘点在不同业务反对过的此类场景，总结DAG面临以下痛点：
- 产品业务逻辑简单，且状态差别大
- 款式丰盛，交互简单且有较高视觉品质诉求
- 定制性要求高，开发速度要求快
解决方案
小蝴蝶(https://github.com/alibaba/butterfly)脱胎于阿里云数据智能事业部理论的业务场景，在笼罩了咱们业务需要的状况下，同时反对了多个兄弟部门形象进去的前端图组件库，其个性如下：
- “整机式开发”，定制性强，入门门槛低：利用了DOM的便利性，提供十分弱小的款式定制和简单的交互定制的能力
// 继承式的定制const Node = require('butterfly-dag').Node;class ANode extends Node { draw(obj) { // "整机式"开发，把最终的dom返回给我即可 } // 随便本人拓展办法 }canvas.draw({ nodes: [{ id: 'xxxx', top: 100, left: 100, Class: ANode //设置基类之后，画布会依据自定义的类来渲染 }]})- 画布惯例性能一应俱全：Minmap、网格零碎、对齐线、框选、redo/undo、画布缩放和平移、线段动画、主动布局等等。
- 更细腻更人性化的交互，后续咱们将花更多的精力聚焦更智能的交互：
- 聚焦局部节点 & 聚焦画布
- 框选更智能化。管制框选交互：触碰即选中或者是齐全蕴含才选中；管制可选元素：锚点，节点，线段
- 拖动边缘处的解决
- 成组的优化
性能问题
已经很多人都质疑咱们，小蝴蝶应用DOM，那性能不会很差么？咱们小蝴蝶专一于流程图，为了确保咱们业务的完整性和清晰度，咱们的定位是：10000个节点为性能的极限，因为超过了10000个节点，整个业务流程会变得凌乱不堪。与此同时，咱们做了十分多的性能优化的工作：
- 分层渲染。各层互不影响，并且确保渲染达到更细的粒度
- 首屏逐渐渲染。确保画布的首次展现能靠近Canvas的渲染速度
- 部分渲染。确保每各元素的每次更改都是最小粒度地渲染，不会触发大面积地从新渲染
- 批量操作。把画布内所有元素增删查改都是优化为批量操作，确保尽可能少地操作DOM
单干共建
咱们常常被问到小蝴蝶和G6有什么关系？咱们和AntV-G6推出的工夫差不多，堪称亦师亦友，竞争共建，大家都是为了独特推动这个畛域的倒退而致力。咱们常常和@聚则 交换沟通，为了缩小反复建设，咱们初步制订了第一阶段的打算，也在致力推动中：
针对第二阶段的单干共建，咱们最近一直在思考，小蝴蝶胜在定制性比拟好上手简略但性能上不能反对1w以上的节点，G6渲染引擎是Canvas性能是比拟优良然而定制性有所欠缺入门门槛也会绝对高一点。咱们能不能把两者长处联合下，取其精华，去其糟粕。咱们的构想是：
- _第一层_： 当鼠标浮动下面须要编辑的时候，对应的某个节点会呈现在DOM层，把Canvas相应的节点笼罩着
- _第二层_： 当不须要编辑的时候，Canvas作为真正的渲染引擎
- _第三层_： 背景和框选等操作层为不常变动层
这块咱们曾经在踊跃调研中了，期间咱们发现在Html to Canvas的时候会损失了一部分CSS的个性，但这部分个性能够由Canvas来补救。心愿在这年度能冲破这个难关，真正能把DOM和Canvas交融起来，把性能和定制施展到极致，帮忙更多的有须要的同学.
将来的布局
感激阿里云设计核心，DataV的兄弟们和其余贡献者 这三年来的添砖加瓦 ，这个年度咱们会更加致力加强小蝴蝶底层的能力，丰盛小蝴蝶的生态，为打造“零”代码的图编排而致力。
结语
咱们曾经积攒反对了20+个业务，积淀了100+个节点款式，不久的未来会凋谢给小伙伴应用，到时候大家能够像“iconfont”式都组合拼凑，能大大降低了大家的开发工夫。
三年磨一剑，心愿小蝴蝶能为你提供一份助力。小蝴蝶保持开源了三年，您的star是咱们的能源：https://github.com/alibaba/butterfly ，谢谢大家！也同时欢送有趣味的兄弟们一起来添砖加瓦。