关于前端:逻辑编排在优酷可视化搭建中的实践四-编排通用性方向探索

之前的文章讲过 YOHO 平台是因营销搭建平台的需要而诞生的，而后咱们有了让它可能服务到更多平台的想法。三月底的时候，直播业务的同学找到咱们，心愿可能借助咱们的平台实现编排。彼时的 YOHO 还不足以承接外来业务，所以在 4 月份开始了通用性的革新。

G6 到 X6

YOHO 早前是基于 G6 开发的，逻辑编排对图形编辑的要求比拟高，而 G6 更加侧重于图形展现、数据可视化，以及基于 canvas 的高性能。团队的小伙伴最后通过 G6 实现了一版编排，能力都没问题。起初想要一直优化画布能力的时候，就比拟累心了。

无论是对齐还是连接线门路计算，都须要本人实现。对图形能够自在编辑也是有诉求的，这些都是开发量，须要人力与工夫。X6 则不同，它的强点就在图形编辑上，能够说图形操作的所有辅助能力你都不须要去关怀，因为它都内置了能力反对。咱们违心破费一点工夫从 G6 切到 X6，因为他会为咱们前期节俭更多的工夫。

另一方面，G6 绘制图形只能通过 G6 提供的 Shape 属性绘制或者类 JSX 语法来自定义节点，对于会有丰盛图形的场景，让接入的同学去绘制，还是须要肯定的老本的。而 X6 你能够通过 HTML 或者 React 或者 Vue 进行渲染，这个对于咱们来说是更加相熟的。

所以，从 G6 向 X6 的转换正是基于两点思考：

1. X6 精于图形编辑，G6 精于数据可视化
2. X6 比 G6 更加容易上手开发
3. 编排场景对性能要求不高，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 做的是编排这个方向上的某一模式。