优酷视觉构建中的逻辑编排实践（四）——探索编排通用化平台思路的方向。3月底，直播业务的同学找到我们，希望借助我们的平台实现编排。当时YOHO不足以承接国外业务，4月份开始全面转型。G6到X6YOHO是早期基于G6开发的。逻辑布局对图形编辑的要求比较高，而G6更侧重于图形展示、数据可视化和基于canvas的高性能。团队的小伙伴通过G6初步实现了一个版本的编排，能力还行。后来想不断优化canvas能力的时候，就比较累了。不管是走线还是连接线路径计算，都需要自己去实现。还有免费编辑图文的需求，开发量大，需要人力和时间。X6是不同的。它的优势在于图形编辑。可以说你不需要关心图形运算的所有辅助能力，因为它有内置的能力支持。我们愿意花一点时间从G6切换到X6，因为这会在后期为我们节省更多的时间。另一方面，G6只能通过G6提供的Shape属性或类JSX语法自定义节点来绘制图形。对于图形丰富的场景，连接的同学绘制还是需要一定的成本。有了X6，你可以通过我们比较熟悉的HTML或者React或者Vue来渲染。因此，从G6到X6的转换是基于两方面的考虑：X6擅长图形编辑，G6擅长数据可视化。X6比G6更容易使用。开发和编排场景对性能要求不高，X6可以满足要求。从G6到G6的通用性X6的改造只能在短时间内保证canvas能力的完备性，但是如何让canvas更加通用呢？这就是我们所说的YOHO的定位——让用户一站式接入节目。一站式是因为我们希望用户可以在线定制他们的编排业务。这个想法是基于两个考虑。一是前端同学可以快速访问，二是非前端同学在不懂前端开发的情况下也可以访问。YOHO目前并不打算打造一个可以应对所有场景的平台，它会有自己的能力。比如目前我们只支持流程图的编排，业务方要方块图的编排，这就超出了我们的能力范围。滴滴前段时间开源的Logic-Flow，在内部被一些中后端开发者使用。看了下基于X6的二次设计，没有能力提升。与X6相比，API设计只是自己梳理，也增加了学习成本。观察他们发布的一些案例，很多平台的用法并没有太大区别，无非就是图表的风格不同。所以如果我们拆解编排，提取一些API，进行可视化配置，就可以快速接入编排。布局根据每个区域进行划分。元件面板可根据不同需求开发四种布局供用户选择；画布分解图、节点和边，如下所述；属性面板是基于FormRenderBuild的可视化表单。对于非表单类型，如表达式编辑器，可以提供源码开发方式。arrangercanvas的绘制看代码开发初始化一个canvas，需要怎么描述：constgraph=newGraph({container:document.getElementById('container'),width:800,height:600,//nodeRotating:false,//节点是否可以缩放resizing:true,//背景配置background:{color:'#f8f9fa',},//网格配置grid:{visible:true,},.........});其实X6有很多配置项，包括可以通过函数灵活配置一些canvas。这些部分只是一些配置项。如果我们对它们进行可视化配置，这部分画布的问题就迎刃而解了。节点绘制绘制节点：constrect=newShape.Rect({x:100,y:40,width:100,height:40,attrs:{body:{fill:'#2ECC71',//背景颜色stroke:'#000',//边框颜色},label:{text:'rect',//文本填充:'#333',//文本颜色fontSize:13,//文本大小},},})constrect=newShape.Rect({x:100,y:40,width:100,height:40,attrs:{body:{fill:'#2ECC71',//背景颜色stroke:'#000',//边框color},label:{text:'rect',//textfill:'#333',//textcolorfontSize:13,//textsize},},})基于提供的属性我们还可以绘制更多比较复杂的节点，但是有两个问题，一是svg学习的成本，二是有些自定义的节点不能根据已有的属性来绘制，比如：如果我们像react组件一样开发这个节点就简单多了.在YOHO中，节点开发的组成如下：-shape|--index.tsx|--node.tsx|--thumb.tsx节点可以分为两个部分，一个是左侧组件面板中的缩略图展示，一种是canvas中的显示，分别在thumb.tsx和node.tsx中完成，由index.tsx导出。同时需要在index.tsx中定义节点的端口（连接点）。基于此，我们将画布和图形解耦，提出了一个概念，图形库。这些节点开发完成后会保存在库中，图形可以共享。如果您的业务需要某种图形，您可以将图形引入到您的业务中，并在开发组件时将其与图形关联起来。如果你需要的图形已经存在于图形库中，你可能真的没有开发可言。画边画边没有太多的特例，基本上都是根据已有的属性来做可视化的配置。edge.attr({line:{sourceMarker:'block',targetMarker:{name:'ellipse',rx:10,//椭圆箭头的x半径ry:6,//椭圆箭头的y半径},},})窗体的普通编辑不包括流程的绘制，以及各组件属性的配置。我们使用JSON来描述属性，那么如果我们想要能够配置这些属性，就必须要有一个可以可视化配置的表单，即schema2Form。我们基于该组的开源FormRender来执行此操作。FormRender还提供了可视化构建表单的工具fr-generator，方便我们拖拽生成表单。另一种情况是它不是普通的形式。以Mendix的表达式编辑器为例，这不是表格。我们应该做什么？目前给出的解决方案是可以用源码开发属性面板。我们可以选择两种模式，一种是JSONSchema，基于FR；另一种是源码开发，发布后产生CDN文件，布局时选择组件，加载对应的ComponentCDN，渲染。触发逻辑编排完成后，编排引擎会生成GraphJSON，这在YOHO中很常见。首先，每个业务都会有自己的Runtime，也就是逻辑解释器，自然会有自己的DSL，GraphJSON到DSL的转换器。当然，每个企业都是不同的。其次，业务方可能需要将数据落入自己的数据库中。YOHO自然不会把业务DSL存放在自己的库中。YOHO设计了触发机制。商家可以在YOHO上填写自己的触发器。当用户在YOHO平台进行相应的操作时，触发器就会被触发，YOHO会将相应的数据传递给它。作为这篇文章的总结，我想分享一些最近关于编排平台通用性的思考和变化。有的已经实现了，有的还需要投入开发。在开发过程中，我们一直在思考和调整平台未来的发展方向。如果你看了之前的文章，你会发现YOHO的设计思路发生了很大的变化。就像一个行业的某个垂直领域，YOHO做的就是在这个方向上安排某个模式。
