之前的文章讲过YOHO平台是因营销搭建平台的需求而诞生的，而后我们有了让它能够服务到更多平台的想法。三月底的时候，直播业务的同学找到我们，希望能够借助我们的平台实现编排。彼时的YOHO还不足以承接外来业务，所以在4月份开始了通用性的改造。
G6到X6
YOHO早前是基于G6开发的，逻辑编排对图形编辑的要求比较高，而G6更加侧重于图形展示、数据可视化，以及基于canvas的高性能。团队的小伙伴最初通过G6实现了一版编排，能力都没问题。后来想要不断优化画布能力的时候，就比较累心了。
无论是对齐还是连接线路径计算，都需要自己实现。对图形可以自由编辑也是有诉求的，这些都是开发量，需要人力与时间。X6则不同，它的强点就在图形编辑上，可以说图形操作的一切辅助能力你都不需要去关心，因为它都内置了能力支持。我们愿意花费一点时间从G6切到X6，因为他会为我们后期节省更多的时间。
另一方面，G6 绘制图形只能通过 G6 提供的 Shape 属性绘制或者类 JSX 语法来自定义节点，对于会有丰富图形的场景，让接入的同学去绘制，还是需要一定的成本的。而X6你可以通过 HTML 或者 React 或者 Vue 进行渲染，这个对于我们来说是更加熟悉的。
所以，从G6向X6的转换正是基于两点考虑：
- X6精于图形编辑，G6精于数据可视化
- X6比G6更加容易上手开发
- 编排场景对性能要求不高，X6可以满足需求
通用性
从G6到X6的转变只能保障在短时间内画布能力的完备，但是如何让一个画布能够更加通用呢？这就要说一下YOHO的定位了——让用户一站式接入编排。一站式是因为我们希望用户能够在线定制他们的编排业务，有这个想法是基于两点考虑，一是前端同学可以快速接入，二是非前端同学不了解前端开发也有能力接入。YOHO目前没有想去做一个能够所有场景的平台，它会有它的能力边界。比如当前我们只支持流程图的编排，业务方想要一个积木图编排，这就是我们的能力范围之外了。
滴滴前段时间开源的 Logic-Flow，在他们内部有一些中后台在使用。看了一下基于X6进行了二次设计，并没有能力的增强，API的设计与X6比，也只是做了一个他们自己的梳理，还增加了学习成本。观察他们放出的一些案例，很多平台之间的使用区别并不大，无非是图的样式不太一样。
所以如果我们把编排进行拆解，抽离一些API，进行可视化配置，是可以快速接入编排的。
将编排根据各个区域进行划分，元件面板可以根据不同的诉求，开发四种版型，让接入者选择；画布进行图、节点、边的拆解，具体在下方介绍；属性面板我们基于Form Render进行可视化表单搭建，对于非表单类型的，比如表达式编辑器这种，可以提供源码开发方式。
编排器
画布的绘制
我们来看看如果代码开发初始化一个画布，我们需要如何描述：
const graph = new Graph({ container: document.getElementById('container'), width: 800, height: 600, // 节点是否可旋转 rotating: false, // 节点是否可调整大小 resizing: true, // 背景配置 background: { color: '#f8f9fa', }, // 网格配置 grid: { visible: true, }, ... ... ... }); 实际上X6有很多的配置项，也包括通过函数去灵活配置一些画布的能力。这部分都是一些配置项而已，如果我们针对它们进行可视化的配置，画布的这部分问题就解决了。
节点的绘制
绘制一个节点：
const rect = new Shape.Rect({ x: 100, y: 40, width: 100, height: 40, attrs: { body: { fill: '#2ECC71', // 背景颜色 stroke: '#000', // 边框颜色 }, label: { text: 'rect', // 文本 fill: '#333', // 文字颜色 fontSize: 13, // 文字大小 }, }, })const rect = new Shape.Rect({ x: 100, y: 40, width: 100, height: 40, attrs: { body: { fill: '#2ECC71', // 背景颜色 stroke: '#000', // 边框颜色 }, label: { text: 'rect', // 文本 fill: '#333', // 文字颜色 fontSize: 13, // 文字大小 }, }, }) 基于提供的属性我们还能够绘制更加复杂一点的节点，但是有两个问题，一个是svg学习的成本，第二个是基于现有的属性有一些定制的节点是绘制不出来的，比如：
如果我们像开发react组件一样，来开发这个节点，就简单多了。
在YOHO中，节点开发的构成如下：
- shape |-- index.tsx |-- node.tsx |-- thumb.tsx 节点可以分为两个部分，一个是左边的元件面板中的缩略展示，一个是画布中的展示，分别在 thumb.tsx 和 node.tsx 中完成，由 index.tsx 导出，同时在 index.tsx 中需要定义节点的 port(连接点) 。
基于此，我们将画布与图形进行了解耦，拓展出了一个概念，图形库。这些节点开发后都会入库，图形可以进行共享，如果你的业务需要某个图形，可以将图形引入你的业务，开发元件的时候和图形进行关联。如果你所需要的图形在图形库中都已经有了，可能你真的一点开发量都没有了。
边的绘制
边的绘制没有太多特殊情况，基本是基于现有的属性去做可视化配置就行了。
edge.attr({ line: { sourceMarker: 'block', targetMarker: { name: 'ellipse', rx: 10, // 椭圆箭头的 x 半径 ry: 6, // 椭圆箭头的 y 半径 }, }, }) 表单通用性
编排除了流程的绘制以外，还有每个元件的属性的配置。属性我们都是用 JSON 来进行描述，那想要能够配置这些属性，就是要有能够可视化配置的表单，也就是 schema2Form。这一点，我们是基于集团开源的 Form Render 来做的。Form Render 同时提供了一个可视化搭建表单的工具 fr-generator ，方便我们拖拽生成表单。
还有一种场景，就是不是普通的表单，拿Mendix的表达式编辑器来说，这就不是个表单，我们应该怎么办？目前给出的解法是，属性面板是可以源码开发的。
我们可以选择两种模式，一种是JSON Schema，也就是基于FR的那种；另一种就是源码开发，发布后产出cdn文件，在编排时选中元件，加载对应的Component CDN，将其渲染。
触发器
逻辑编排完成后，编排引擎会生成 Graph JSON，这是 YOHO 中通用的。一来每个业务会有自己的 Runtime，也就是逻辑解释器，自然也就有自己的 DSL ，Graph JSON 到 DSL 的转换器，自然每个业务不尽相同。二来业务方可能需要将数据落到自己的数据库中。那自然，YOHO就不会在自己的库里存储业务的 DSL 了。
YOHO 设计了触发器机制，业务在YOHO上可以填写自己的触发器，当用户在YOHO平台进行了对应的操作时，触发器就会触发，YOHO会将相应的数据传递过去。
总结
这篇文章是想分享一下最近关于编排平台通用性的一点思考与改动，其中有一部分已经实现了，有一部分还需要投入精力开发。对于平台未来的方向在开发过程中也一直在思考，一直在调整。如果各位看官有看前面的文章，可以发现，YOHO的设计思路已经有了很大的转变。就像是一个行业中的某一垂直领域，YOHO做的是编排这个方向上的某一模式。
原文链接：https://blog.csdn.net/alienttech/article/details/121341125?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165934461816780357226309%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165934461816780357226309&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-7-121341125-null-null.nonecase&utm_term=%E6%90%AD%E5%BB%BAcdn
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/8284
