逻辑编排在优酷可视化搭建中的实践（四） - 编排通用性方向探索

之前的文章讲过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做的是编排这个方向上的某一模式。

逻辑编排在优酷可视化搭建中的实践（四） - 编排通用性方向探索

G6到X6

通用性

编排器

总结

猜你喜欢