前、后端通用的可视化逻辑编排
前一段时间写过一篇文章《实战，一个高扩展、可视化低代码前端，详实、完整》，得到了很多朋友的关注。
其中的逻辑编排部分过于简略，不少朋友希望能写一些关于逻辑编排的内容，本文就详细讲述一下逻辑编排的实现原理。
逻辑编排的目的，是用最少甚至不用代码来实现软件的业务逻辑，包括前端业务逻辑跟后端业务逻辑。本文前端代码基于typescript、react技术栈，后端基于golang。
涵盖内容：数据流驱动的逻辑编排原理，业务编排编辑器的实现，页面控件联动，前端业务逻辑与UI层的分离，子编排的复用、自定义循环等嵌入式子编排的处理、事务处理等
运行快照：
前端项目地址：https://github.com/codebdy/rxdrag
前端演示地址：https://rxdrag.vercel.app/
后端演示尚未提供，代码地址：https://github.com/codebdy/minions-go
注：为了便于理解，本文使用的代码做了简化处理，会跟实际代码有些细节上的出入。
整体架构
整个逻辑编排，由以下几部分组成：
- 节点物料，用于定义编辑器中的元件，包含在工具箱中的图标，端口以及属性面板中的组件schema。
- 逻辑编排编辑器，顾名思义，可视化编辑器，根据物料提供的元件信息，编辑生成JSON格式的“编排描述数据”。
- 编排描述数据，用户操作编辑器的生成物，供解析引擎消费
- 前端解析引擎，Typescript 实现的解析引擎，直接解析“编排描述数据”并执行，从而实现的软件的业务逻辑。
- 后端解析引擎，Golang 实现的解析引擎，直接解析“编排描述数据”并执行，从而实现的软件的业务逻辑。
逻辑编排实现方式的选择
逻辑编排，实现方式很多，争议也很多。
一直以来，小编的思路也很局限。从流程图层面，以线性的思维去思考，认为逻辑编排的意义并不大。因为，经过这么多年发展，事实证明代码才是表达逻辑的最佳方式，没有之一。用流程图去表达代码，最终只能是老板、客户的丰满理想与程序员骨感现实的对决。
直到看到Mybricks项目交互部分的实现方式，才打开了思路。类似unreal蓝图数据流驱动的实现方式，其实大有可为。
这种方式的意义是，跳出循环、if等这些底层的代码细节，以数据流转的方式思考业务逻辑，从而把业务逻辑抽象为可复用的组件，每个组件对数据进行相应处理或者根据数据执行相应动作，从而达到复用业务逻辑的目的。并且，节点的粒度可大可小，非常灵活。
具体实现方式是，把每个逻辑组件看成一个黑盒，通过入端口流入数据，出端口流出变换后的数据：
举个例子，一个节点用来从数据库查询客户列表，会是这样的形式：
用户不需要关注这个元件节点的实现细节，只需要知道每个端口的功能就可以使用。这个元件节点的功能可以做的很简单，比如一个fetch，只有几十行代码。也可以做到很强大，比如类似useSwr，自带缓存跟状态管理，可以有几百甚至几千行代码。
我们希望这些元件节点是可以自行定义，方便插入的，并且我们做到了。
出端口跟入端口之间，可以用线连接，表示元件节点之间的调用关系，或者说是数据的流入关系。假如，数据读取成功，需要显示在列表中；失败，提示错误消息；查询时，显示等待的Spinning，那么就可以再加三个元件节点，变成：
如果用流程图，上面这个编排，会被显示成如下样子：
两个比较，就会发现，流程图的思考方式，会把人引入条件细节，其实就是试图用不擅长代码的图形来描述代码。是纯线性的，没有回调，也就无法实现类似js promise的异步。
而数据流驱动的逻辑编排，可以把人从细节中解放出来，用模块化的思考方式去设计业务逻辑，更方便把业务逻辑拆成一个个可复用的单元。
如果以程序员的角度来比喻，流程图相当于一段代码脚本，是面向过程的；数据流驱动的逻辑编排像是几个类交互完成一个功能，更有点面向对象的感觉。
朋友，如果是让你选，你喜欢哪种方式？欢迎留言讨论。
另外还有一种类似stratch的实现方式：
感觉这种纯粹为了可视化而可视化，只适合小孩子做玩具。会写代码的人不愿意用，太低效了。不会写代码的人，需要理解代码才会用。适合场景是用直观的方式介绍什么是代码逻辑，就是说只适合相对比较低智力水平的编程教学，比如幼儿园、小学等。商业应用，就免了。
数据流驱动的逻辑编排
一个简单的例子
从现在开始，放下流程图，忘记strach，我们从业务角度去思考也逻辑，然后设计元件节点去实现相应的逻辑。
选一个简单又典型的例子：学生成绩单。一个成绩单包含如下数据：
假如数据已经从数据库取出来了，第一步处理，统计每个学生的总分数。设计这么几个元件节点来配合完成：
这个编排，输入成绩列表，循环输出每个学生的总成绩。为了完成这个编排，设计了四个元件节点：
- 循环，入端口接收一个列表，遍历列表并循环输出，每一次遍历往“单次输出”端口发送一条数据，可以理解为一个学生对象（尽量从对象的角度思考，而不是数据记录），遍历结束后往“结束端口”发送循环的总数。如果按照上面的列表，“单次输出端口”会被调用4次，每次输出一个学生对象{姓名：xxx，语文：xxx，数学：xxx...}，“结束”端口只被调用一次，输出结果是 4.
- 拆分对象，这个元件节点的出端口是可以动态配置的，它的功能是把一个对象按照属性值按照名字分发到指定的出端口。本例中，就是把各科成绩拆分开来。
- 收集数组，这个节点也可以叫收集到数组，作用是把串行接收到的数据组合到一个数组里。他有两个入端口：input端口，用来接收串行输入，并缓存到数组；finished端口，表示输入完成，把缓存到的数据组发送给输出端口。
- 加和，把输入端口传来的数组进行加和计算，输出总数。
这是一种跟代码完全不同的思考方式，每一个元件节点，就是一小段业务逻辑，也就是所谓的业务逻辑组件化。我们的项目中，只提供给了有限的预定义元件节点，想要更多的节点，可以自行自定义并注入系统，具体设计什么样的节点，完全取决于用户的业务需求跟喜好。作者更希望设计元件的过程是一个创作的过程，或许具备一定的艺术性。
刚刚的例子，审视之。有人可能会换一个方式来实现，比如拆分对象跟收集数据这两个节点，合并成一个节点：对象转数组，可能更方便，适应能力也更强：
对象转换数组节点，对象属性与数组索引的对应关系，可以通过属性面板的配置来完成。
这两种实现方式，说不清哪种更好，选择自己喜欢的，或者两种都提供。
输入节点、输出节点
一段图形化的逻辑编排，通过解析引擎，会被转换成一段可执行的业务逻辑。这段业务逻辑需要跟外部对接，为了明确对接语义，再添加两个特殊的节点元件：输入节点（开始节点），输出节点（结束节点）。
输入节点用于标识逻辑编排的入口，输入节点可以有一个或者多个，输入节点用细线圆圈表示。
输出节点用于标识逻辑编排的出口，输出节点可以有一个或者多个，输出节点用粗线圆圈表示。
在后面的引擎部分，会详细描述输入跟输出节点如何跟外部的对接。
编排的复用：子编排
一般低代码中，提升效率的方式是复用，尽可能复用已有的东西，比如组件、业务逻辑，从而达到降本、增效的目的。
设计元件节点是一种创作，那么使用元件节点进行业务编排，更是一种基于领域的创作。辛辛苦苦创作的编排，如果能被复用，应该算是对创作本身的尊重吧。
如果编排能够像元件节点一样，被其它逻辑编排所引用，那么这样的复用方式无疑是最融洽的。也是最方便的实现方式。
把能够被其它编排引用的编排称为子编排，上面计算学生总成绩的编排，转换成子编排，被引入时的形态应该是这样的：
子编排元件的输入端口对应逻辑编排实现的输入节点，输出端口对应编排实现的输出节点。
嵌入式编排节点
前文设计的循环组件非常简单，循环直接执行到底，不能被中断。但是，有的时候，在处理数据的时候，要根据每次遍历到的数据做判断，来决定继续循环还是终止循环。
就是说，需要一个循环节点，能够自定义它的处理流程。依据这个需求，设计了自定义循环元件，这是一种能够嵌入编排的节点，形式如下：
这种嵌入式编排节点，跟其它元件节点一样，事先定义好输入节点跟输出节点。只是它不完全是黑盒，其中一部分通过逻辑编排这种白盒方式来实现。
这种场景并不多见，除了循环，后端应用中，还有事务元件也需要类似实现方式：
嵌入式元件跟其它元件节点一样，可以被其它元件连接，嵌入式节点在整个编排中的表现形式：
基本概念
为了进一步深入逻辑编排引擎跟编辑器的实现原理，先梳理一些基本的名词、概念。
逻辑编排，本文特指数据流驱动的逻辑编排，是由图形表示的一段业务逻辑，由元件节点跟连线组成。
元件节点，简称元件、节点、编排元件、编排单元。逻辑编排中具体的业务逻辑处理单元，带副作用的，可以实现数据转换、页面组件操作、数据库数据存取等功能。一个节点包含零个或多个输入端口，包含零个或多个输出端口。在设计其中，以圆角方形表示：
端口，分为输入端口跟输出端口两种。是元件节点流入或流出数据的通道（或者接口）。在逻辑单元中，用小圆圈表示。
输入端口，简称入端口、入口。输入端口位于元件节点的左侧。
输出端口，简称出端口、出口。输出端口位于元件节点的右侧。
单入口元件，只有一个入端口的元件节点。
多入口元件，有多个入端口的元件节点。
单出口元件，只有一个出端口的元件节点。
多出口元件，有多个出端口的元件节点。
输入节点，一种特殊的元件节点，用于描述逻辑编排的起点（开始点）。转换成子编排后，会对应子编排相应的入端口。
输出节点，一种特殊的元件节点，用于描述逻辑编排的终点（结束点）。转换成子编排后，会对应子编排相应的出端口。
嵌入式编排，特殊的元件节点，内部实现由逻辑编排完成。示例：
子编排，特殊的逻辑编排，该编排可以转换成元件节点，供其它逻辑编排使用。
连接线，简称连线、线。用来连接各个元件节点，表示数据的流动关系。
定义DSL
逻辑编排编辑器生成一份JSON，解析引擎解析这份JSON，把图形化的业务逻辑转化成可执行的逻辑，并执行。
编辑器跟解析引擎之间要有份约束协议，用来约定JSON的定义，这个协议就是这里定义的DSL。在typescript中，用interface、enum等元素来表示。
这些DSL仅仅是用来描述页面上的图形元素，通过activityName属性跟具体的实现代码逻辑关联起来。比如一个循环节点，它的actvityName是Loop，解析引擎会根据Loop这个名字找到该节点对应的实现类，并实例化为一个可执行对象。后面的解析引擎会详细展开描述这部分。
节点类型
元件节点类型叫NodeType，用来区分不同类型的节点，在TypeScript中是一个枚举类型。
export enum NodeType {
//开始节点
Start = 'Start',
//结束节点
End = 'End',
//普通节点
Activity = 'Activity',
//子编排，对其它编排的引用
LogicFlowActivity = "LogicFlowActivity",
//嵌入式节点，比如自定义逻辑编排
EmbeddedFlow = "EmbeddedFlow"
}
端口
export interface IPortDefine {
//唯一标识
id: string;
//端口名词
name: string;
//显示文本
label?: string;
}
元件节点
//一段逻辑编排数据
export interface ILogicFlowMetas {
//所有节点
nodes: INodeDefine<unknown>[];
//所有连线
lines: ILineDefine[];
}
export interface INodeDefine<ConfigMeta = unknown> {
//唯一标识
id: string;
//节点名称，一般用于开始结束、节点，转换后对应子编排的端口
name?: string;
//节点类型
type: NodeType;
//活动名称，解析引擎用，通过该名称，查找构造节点的具体运行实现
activityName: string;
//显示文本
label?: string;
//节点配置
config?: ConfigMeta;
//输入端口
inPorts?: IPortDefine[];
//输出端口
outPorts?: IPortDefine[];
//父节点，嵌入子编排用
parentId?: string;
// 子节点，嵌入编排用
children?: ILogicFlowMetas
}
连接线
//连线接头
export interface IPortRefDefine {
//节点Id
nodeId: string;
//端口Id
portId?: string;
}
//连线定义
export interface ILineDefine {
//唯一标识
id: string;
//起点
source: IPortRefDefine;
//终点
target: IPortRefDefine;
}
逻辑编排
//这个代码上面出现过，为了使extends更直观，再出现一次
//一段逻辑编排数据
export interface ILogicFlowMetas {
//所有节点
nodes: INodeDefine<unknown>[];
//所有连线
lines: ILineDefine[];
}
//逻辑编排
export interface ILogicFlowDefine extends ILogicFlowMetas {
//唯一标识
id: string;
//名称
name?: string;
//显示文本
label?: string;
}
解析引擎的实现
解析引擎有两份实现：Typescript实现跟Golang实现。这里介绍基于原理，以Typescript实现为准，后面单独章节介绍Golang的实现方式。也有朋友根据这个dsl实现了C#版自用，欢迎朋友们实现不同的语言版本并开源。
DSL只是描述了节点跟节点之间的连接关系，业务逻辑的实现，一点都没有涉及。需要为每个元件节点制作一个单独的处理类，才能正常解析运行。比如上文中的循环节点，它的DSL应该是这样的：
{
"id": "id-1",
"type": "Activity",
"activityName": "Loop",
"label": "循环",
"inPorts": [
{
"id":"port-id-1",
"name":"input",
"label":""
}
],
"outPorts": [
{
"id":"port-id-2",
"name":"output",
"label":"单次输出"
},
{
"id":"port-id-3",
"name":"finished",
"label":"结束"
}
]
}
开发人员制作一个处理类LoopActivity用来处理循环节点的业务逻辑，并将这个类注册入解析引擎，key为loop。这个类，我们叫做活动（Activity）。解析引擎，根据activityName查找类，并创建实例。LoopActivity的类实现应该是这样：
export interface IActivity{
inputHandler (inputValue?: unknown, portName:string);
}
export class LoopActivity implements IActivity{
constructor(protected meta: INodeDefine<ILoopConfig>) {}
//输入处理
inputHandler (inputValue?: unknown, portName:string){
if(portName !== "input"){
console.error("输入端口名称不正确")
return
}
let count = 0
if (!_.isArray(inputValue)) {
console.error("循环的输入值不是数组")
} else {
for (const one of inputValue) {
this.output(one)
count++
}
}
//输出循环次数
this.next(count, "finished")
}
//单次输出
output(value: unknown){
this.next(value, "output")
}
next(value:unknown, portName:string){
//把数据输出到指定端口,这里需要解析器注入代码
}
}
解析引擎根据DSL，调用inputHanlder，把控制权交给LoopActivity的对象，LoopActivity处理完成后把数据通过next方法传递出去。它只需要关注自身的业务逻辑就可以了。
这里难点是，引擎如何让所有类似LoopActivity类的对象联动起来。这个实现是逻辑编排的核心，虽然实现代码只有几百行，但是很绕，需要静下心来好好研读接下来的部分。
编排引擎的设计
编排引擎类图
LogicFlow类，代表一个完整的逻辑编排。它解析一张逻辑编排图，并执行该图所代表的逻辑。
IActivity接口，一个元件节点的执行逻辑。不同的逻辑节点，实现不同的Activity类，这类都实现IActivity接口。比如循环元件，可以实现为
export class LoopActivity implements IActivity{
id: string
config: LoopActivityConfig
}
LogicFlow类解析逻辑编排图时，根据解析到的元件节点，创建相应的IActivity实例，比如解析到Loop节点的时候，就创建LoopActivity实例。
LogicFlow还有一个功能，就是根据连线，给构建的IActivity实例建立连接关系，让数据能在不同的IActivity实例之间流转。先明白引擎中的数据流，是理解上述类图的前提。
解析引擎中的Jointer
在解析引擎中，数据按照以下路径流动：
有三个节点：节点A、节点B、节点C。数据从节点A的“a-in-1”端口流入，通过一些处理后，从节点A的“a-out-1”端口流出。在“a-out-1”端口，把数据分发到节点B的“b-in-1”端口跟节点C的“c-in-1”端口。在B、C节点以后，继续重复类似的流动。
端口“a-out-1”要把数据分发到端口“b-in-1”和端口“c-in-1”，那么端口“a-out-1”要保存端口“b-in-1”和端口“c-in-1”的引用。就是说在解析引擎中，端口要建模为一个类，端口“a-out-1”是这个类的对象。要想分发数据，端口类跟自身是一个聚合关系。这种关系，让解析引擎中的端口看起来像连接器，故取名Jointer。一个Joniter实例，对应一个元件节点的端口。
在逻辑编排图中，一个端口，可以连接多个其它端口。所以，一个Jointer也可以连接多个其它Jointer。
注意，这是实例的关系，如果对应到类图，就是这样的关系：
Jointer通过调用push方法把数据传递给其他Jointer实例。
connect方法用于给两个Joiner构建连接关系。
用TypeScript实现的话，代码是这样的：
//数据推送接口
export type InputHandler = (inputValue: unknown, context?:unknown) => void;
export interface IJointer {
name: string;
//接收上一级Jointer推送来的数据
push: InputHandler;
//添加下游Jointer
connect: (jointerInput: InputHandler) => void;
}
export class Jointer implements IJointer {
//下游Jonter的数据接收函数
private outlets: IJointer[] = []
constructor(public id: string, public name: string) {
}
//接收上游数据，并分发到下游
push: InputHandler = (inputValue?: unknown, context?:unknown) => {
for (const jointer of this.outlets) {
//推送数据
jointer.push(inputValue, context)
}
}
//添加下游Joninter
connect = (jointer: IJointer) => {
//往数组加数据，跟上面的push不一样
this.outlets.push(jointer)
}
//删除下游Jointer
disconnect = (jointer: InputHandler) => {
this.outlets.splice(this.outlets.indexOf(jointer), 1)
}
}
在TypeScript跟Golang中，函数是一等公民。但是在类图里面，这个独立的一等公民是不好表述的。所以，上面的代码只是对类图的简单翻译。在实现时，Jointer的outlets可以不存IJointer的实例，只存Jointer的push方法，这样的实现更灵活，并且更容易把一个逻辑编排转成一个元件节点，优化后的代码：
//数据推送接口
export type InputHandler = (inputValue: unknown, context?:unknown) => void;
export interface IJointer {
//当key使用，不参与业务逻辑
id: string;
name: string;
//接收上一级Jointer推送来的数据
push: InputHandler;
//添加下游Jointer
connect: (jointerInput: InputHandler) => void;
}
export class Jointer implements IJointer {
//下游Jonter的数据接收函数
private outlets: InputHandler[] = []
constructor(public id: string, public name: string) {
}
//接收上游数据，并分发到下游
push: InputHandler = (inputValue?: unknown, context?:unknown) => {
for (const jointerInput of this.outlets) {
jointerInput(inputValue, context)
}
}
//添加下游Joninter
connect = (inputHandler: InputHandler) => {
this.outlets.push(inputHandler)
}
//删除下游Jointer
disconnect = (jointer: InputHandler) => {
this.outlets.splice(this.outlets.indexOf(jointer), 1)
}
}
记住这里的优化：Jointer的下游已经不是Jointer了，是Jointer的push方法，也可以是独立的其它方法，只要参数跟返回值跟Jointer的push方法一样就行，都是InputHandler类型。这个优化，可以让把Activer的某个处理函数设置为入Jointer的下游，后面会有进一步介绍。
Activity与Jointer的关系
一个元件节点包含多个（或零个）入端口和多个（或零个）出端口。那么意味着一个IActivity实例包含多个Jointer，这些Jointer也按照输入跟输出来分组：
TypeScript定义的代码如下：
export interface IActivityJointers {
//入端口对应的连接器
inputs: IJointer[];
//处端口对应的连接器
outputs: IJointer[];
//通过端口名获取出连接器
getOutput(name: string): IJointer | undefined
//通过端口名获取入连接器
getInput(name: string): IJointer | undefined
}
//活动接口，一个实例对应编排图一个元件节点，用于实现元件节点的业务逻辑
export interface IActivity<ConfigMeta = unknown> {
id: string;
//连接器，跟元件节点的端口异议对应
jointers: IActivityJointers,
//元件节点配置，每个Activity的配置都不一样，故而用泛型
config?: ConfigMeta;
//销毁
destory(): void;
}
入端口挂接业务逻辑
入端口对应一个Jointer，这个Jointer的连接关系：
逻辑引擎在解析编排图元件时，会给每一个元件端口创建一个Jointer实例：
//构造Jointers
for (const out of activityMeta.outPorts || []) {
//出端口对应的Jointer
activity.jointers.outputs.push(new Jointer(out.id, out.name))
}
for (const input of activityMeta.inPorts || []) {
//入端口对应的Jointer
activity.jointers.inputs.push(new Jointer(input.id, input.name))
}
新创建的Jointer，它的下游是空的，就是说成员变量的outlets数组是空的，并没有挂接到真实的业务处理。要调用Jointer的connect方法，把Activity的处理函数作为下游连接过去。
最先想到的实现方式是Acitvity有一个inputHandler方法，根据端口名字分发数据到相应处理函数：
export interface IActivity<ConfigMeta = unknown> {
id: string;
//连接器，跟元件节点的端口异议对应
jointers: IActivityJointers,
//元件节点配置，每个Activity的配置都不一样，故而用泛型
config?: ConfigMeta;
//入口处理函数
inputHandler(portName:string, inputValue: unknown, context?:unknown):void
//销毁
destory(): void;
}
export abstract class SomeActivity implements IActivity<SomeConfigMeta> {
id: string;
jointers: IActivityJointers;
config?: SomeConfigMeta;
constructor(public meta: INodeDefine<ConfigMeta>) {
this.id = meta.id
this.jointers = new ActivityJointers()
this.config = meta.config;
}
//入口处理函数
inputHandler(portName:string, inputValue: unknown, context?:unknown){
switch(portName){
case PORTNAME1:
port1Handler(inputValue, context)
break
case PORTNAME2:
...
break
...
}
}
//端口1处理函数
port1Handler = (inputValue: unknown, context?:unknown)=>{
...
}
destory = () => {
//销毁处理
...
}
}
LogicFlow解析编排JSON，碰到SomeActivity对应的元件时，如下处理：
//创建SomeActivity实例
const someNode = new SomeActivity(meta)
//构造Jointers
for (const out of activityMeta.outPorts || []) {
//出端口对应的Jointer
activity.jointers.outputs.push(new Jointer(out.id, out.name))
}
for (const input of activityMeta.inPorts || []) {
//入端口对应的Jointer
const jointer = new Jointer(input.id, input.name)
activity.jointers.inputs.push(jointer)
//给入口对应的连接器，挂接输入处理函数
jointer.connect(someNode.inputHandler)
}
业务逻辑挂接到出端口
入口处理函数，处理完数据以后，需要调用出端口连接器的push方法，把数据分发出去：
具体实现代码：
export abstract class SomeActivity implements IActivity<SomeConfigMeta> {
jointers: IActivityJointers;
...
//入口处理函数
inputHandler(portName:string, inputValue: unknown, context?:unknown){
switch(portName){
case PORTNAME1:
port1Handler(inputValue, context)
break
case PORTNAME2:
...
break
...
}
}
//端口1处理函数
port1Handler = (inputValue: unknown, context?:unknown)=>{
...
//处理后得到新的值：newInputValue 和新的context：newContext
//把数据分发到相应出口
this.jointers.getOutput(somePortName).push(newInputValue, newContext)
}
...
}
入端口跟出端口，连贯起来，一个Activtity内部的流程就跑通了：
出端口挂接其它元件节点
入端口关联的是Activity的自身处理函数，出端口关联的是外部处理函数，这些外部处理函数有能是其它连接器（Jointer）的push方法，也可能来源于其它跟应用对接的部分。
如果是关联的是其他节点的Jointer，关联关系是通过逻辑编排图中的连线定义的。
解析器先构造完所有的节点，然后遍历一遍连线，调用连线源Jointer的conect方法，参数是目标Jointer的push，就把关联关系构建起来了：
for (const lineMeta of this.flowMeta.lines) {
//先找起始节点，这个后面会详细介绍，现在可以先忽略
let sourceJointer = this.jointers.inputs.find(jointer => jointer.id === lineMeta.source.nodeId)
if (!sourceJointer && lineMeta.source.portId) {
sourceJointer = this.activities.find(reaction => reaction.id === lineMeta.source.nodeId)?.jointers?.outputs.find(output => output.id === lineMeta.source.portId)
}
if (!sourceJointer) {
throw new Error("Can find source jointer")
}
//先找起终止点，这个后面会详细介绍，现在可以先忽略
let targetJointer = this.jointers.outputs.find(jointer => jointer.id === lineMeta.target.nodeId)
if (!targetJointer && lineMeta.target.portId) {
targetJointer = this.activities.find(reaction => reaction.id === lineMeta.target.nodeId)?.jointers?.inputs.find(input => input.id === lineMeta.target.portId)
}
if (!targetJointer) {
throw new Error("Can find target jointer")
}
//重点关注这里，把一条连线的首尾相连，构造起连接关系
sourceJointer.connect(targetJointer.push)
}
特殊的元件节点：开始节点、结束节点
到目前为止，解析引擎部分，已经能够成功解析普通的元件并成功连线，但是一个编排的入口跟出口尚未处理，对应的是编排图的输入节点（开始节点）跟输出节点（结束节点）
这两个节点，没有任何业务逻辑，只是辅助把外部输入，连接到内部的元件；或者把内部的输出，发送给外部。所以，这两个节点，只是简单的Jointer就够了。
如果把一个逻辑编排看作一个元件节点：
输入元件节点对应的是输入端口，输出元件节点对应的是输出端口。既然逻辑编排也有自己端口，那么LogicFlow也要聚合ActivityJointers：
引擎解析的时候，要根据开始元件节点跟结束元件节点，构建LogicFlow的Jointer：
export class LogicFlow {
id: string;
jointers: IActivityJointers = new ActivityJointers();
activities: IActivity[] = [];
constructor(private flowMeta: ILogicFlowDefine) {
...
//第一步，解析节点
this.constructActivities()
...
}
//构建一个图的所有节点
private constructActivities() {
for (const activityMeta of this.flowMeta.nodes) {
switch (activityMeta.type) {
case NodeType.Start:
//start只有一个端口，可能会变成其它流程的端口，所以name谨慎处理
this.jointers.inputs.push(new Jointer(activityMeta.id, activityMeta.name || "input"));
break;
case NodeType.End:
//end 只有一个端口，可能会变成其它流程的端口，所以name谨慎处理
this.jointers.outputs.push(new Jointer(activityMeta.id, activityMeta.name || "output"));
break;
}
...
}
}
}
经过这样的处理，一个逻辑编排就可以变成一个元件节点，被其他逻辑编排所引用，具体实现细节，本文后面再展开叙述。
根据元件节点创建Activity实例
在逻辑编排图中，一种类型的元件节点，在解析引擎中会对应一个实现了IActivity接口的类。比如，循环节点，对应LoopActivity；条件节点，对应ConditionActivity；调试节点，对应DebugActivity；拆分对象节点，对应SplitObjectActivity。
这些Activity要跟具体的元件节点建立一一对应关系，在DSL中以activityName作为关联枢纽。这样解析引擎根据activityName查找相应的Activity类，并创建实例。
工厂方法
如何找到并创建节点单元对应的Activity实例呢？最简单的实现方法，是给每个Activity类实现一个工厂方法，建立一个activityName跟工厂方法的映射map，解析引擎根据这个map实例化相应的Activity。简易代码：
//工厂方法的类型定义
export type ActivityFactory = (meta:ILogiFlowDefine)=>IActivity
//activityName跟工厂方法的映射map
export const activitiesMap:{[activityName:string]:ActivityFactory} = {}
export class LoopActivity implements IActivity{
...
constructor(protected meta:ILogiFlowDefine){}
inputHandler=(portName:string, inputValue:unknown, context:unknown)=>{
if(portName === "input"){
//逻辑处理
...
}
}
...
}
//LoopActivity的工厂方法
export const LoopActivityFactory:ActivityFactory = (meta:ILogiFlowDefine)=>{
return new LoopActivity(meta)
}
//把工厂方法注册进map，跟循环节点的activityName对应好
activitiesMap["loop"] = LoopActivityFactory
//LogicFlow的解析代码
export class LogicFlow {
id: string;
jointers: IActivityJointers = new ActivityJointers();
activities: IActivity[] = [];
constructor(private flowMeta: ILogicFlowDefine) {
...
//第一步，解析节点
this.constructActivities()
...
}
//构建一个图的所有节点
private constructActivities() {
for (const activityMeta of this.flowMeta.nodes) {
switch (activityMeta.type) {
...
case NodeType.Activity:
//查找元件节点对应的ActivityFactory
const activityFactory = activitiesMap[activityMeta.activityName]
if(activityFactory){
//创建Activity实例
this.activities.push(activityFactory(activityMeta))
}else{
//提示错误
}
break;
}
...
}
}
}
引入反射
正常情况下，上面的实现方法，已经够用了。但是，作为一款开放软件，会有大量的自定义Activity的需求。上面的实现方式，会让Activity的实现代码略显繁琐，并且所有的输入端口都要通过switch判断转发到相应处理函数。
我们希望把这部分工作推到框架层做，让具体Activity的实现更简单。所以，引入了Typescipt的反射机制：注解。通过注解自动注册Activity类，通过注解直接关联端口与相应的处理函数，省去switch代码。
代码经过改造以后，就变成这样：
//通过注解注册LoopActivity类
@Activity("loop")
export class LoopActivity implements IActivity{
...
constructor(protected meta:ILogiFlowDefine){}
//通过注解把input端口跟该处理函数关联
@Input("input")
inputHandler=(inputValue:unknown, context:unknown)=>{
//逻辑处理
...
}
...
}
//LogicFlow的解析代码
export class LogicFlow {
id: string;
jointers: IActivityJointers = new ActivityJointers();
activities: IActivity[] = [];
constructor(private flowMeta: ILogicFlowDefine) {
...
//第一步，解析节点
this.constructActivities()
...
}
//构建一个图的所有节点
private constructActivities() {
for (const activityMeta of this.flowMeta.nodes) {
switch (activityMeta.type) {
...
case NodeType.Activity:
//根据反射拿到Activity的构造函数
const activityContructor = ...//此处是反射代码
if(activityContructor){
//创建Activity实例
this.activities.push(activityContructor(activityMeta))
}else{
//提示错误
}
break;
}
...
}
}
}
LogicFlow是框架层代码，用户不需要关心具体的实现细节。LoopActivity的代码实现，明显简洁了不少。
Input注解接受一个参数作为端口名称，参数默认值是input。
还有一种节点，它的输入端口是不固定的，可以动态增加或者删除。比如：
合并节点就是动态入口的节点，它的功能是接收入口传来的数据，等所有数据到齐以后，合并成一个对象转发到输出端口。这个节点，有异步等待的功能。
为了处理这种节点，我们引入新的注解DynamicInput。实际项目中合并节点Activity的完整实现：
import {
AbstractActivity,
Activity,
DynamicInput
} from '@rxdrag/minions-runtime';
import { INodeDefine } from '@rxdrag/minions-schema';
@Activity(MergeActivity.NAME)
export class MergeActivity extends AbstractActivity<unknown> {
public static NAME = 'system.merge';
private noPassInputs: string[] = [];
private values: { [key: string]: unknown } = {};
constructor(meta: INodeDefine<unknown>) {
super(meta);
this.resetNoPassInputs();
}
@DynamicInput
inputHandler = (inputName: string, inputValue: unknown) => {
this.values[inputName] = inputValue;、
//删掉已经收到数据的端口名
this.noPassInputs = this.noPassInputs.filter(name=>name !== inputName)
if (this.noPassInputs.length === 0) {
//next方法，把数据转发到指定出口，第二个参数是端口名，默认值input
this.next(this.values);
this.resetNoPassInputs();
}
};
resetNoPassInputs(){
for (const input of this.meta.inPorts || []) {
this.noPassInputs.push(input.name);
}
}
}
注解DynamicInput不需要绑定固定的端口，所以就不需要输入端口的名称。
子编排的解析
子编排就是一段完整的逻辑编排，跟普通的逻辑编排没有任何区别。只是它需要被其它编排引入，这个引入是通过附加一个Activity实现的。
export interface ISubLogicFLowConfig {
logicFlowId?: string
}
export interface ISubMetasContext{
subMetas:ILogicFlowDefine[]
}
@Activity(SubLogicFlowActivity.NAME)
export class SubLogicFlowActivity implements IActivity {
public static NAME = "system-react.subLogicFlow"
id: string;
jointers: IActivityJointers;
config?: ISubLogicFLowConfig;
logicFlow?: LogicFlow;
//context可以从引擎外部注入的，此处不必纠结它是怎么来的这个细节
constructor(meta: INodeDefine<ISubLogicFLowConfig>, context: ISubMetasContext) {
this.id = meta.id
//通过配置中的LogicFlowId，查找子编排对应的JSON数据
const defineMeta = context?.subMetas?.find(subMeta => subMeta.id === meta.config?.logicFlowId)
if (defineMeta) {
//解析逻辑编排，new LogicFlow 就是解析一段逻辑编排，也可以在别处被调用
this.logicFlow = new LogicFlow(defineMeta, context)
//把解析后的连接器对应到本Activity
this.jointers = this.logicFlow.jointers
} else {
throw new Error("No meta on sub logicflow")
}
}
destory(): void {
this.logicFlow?.destory();
this.logicFlow = undefined;
}
}
因为不需要把端口绑定到相应的处理函数，故该Activity并没有使用Input相关注解。
嵌入式编排的解析
逻辑编排中，最复杂的部分，就是嵌入式编排的解析，希望小编能解释清楚。
再看一遍嵌入式编排的表现形式：
这是自定义循环节点。虽然它端口直接跟内部的编排节点相连，但是实际上这种情况是无法直接调用new LogicFlow 来解析内部逻辑编排的，需要进行转换。引擎解析的时候，把会把上面的子编排重组成如下形式：
首先，给子编排添加输入节点，名称跟ID分别对应自定义循环的入端口名称跟ID；添加输出节点，名称跟ID分别对应自定义循环的出端口名称跟ID。
然后，把一个图中的红色数字标注的连线，替换成第二个图中蓝色数字标注的连线。
容器节点的端口，并不会跟转换后的输入节点或者输出节点直接连接，而是在实现中根据业务逻辑适时调用，故用粗虚线表示。
自定义循环具体实现代码：
import { AbstractActivity, Activity, Input, LogicFlow } from "@rxdrag/minions-runtime";
import { INodeDefine } from "@rxdrag/minions-schema";
import _ from "lodash"
export interface IcustomizedLoopConifg {
fromInput?: boolean,
times?: number
}
@Activity(CustomizedLoop.NAME)
export class CustomizedLoop extends AbstractActivity<IcustomizedLoopConifg> {
public static NAME = "system.customizedLoop"
public static PORT_INPUT = "input"
public static PORT_OUTPUT = "output"
public static PORT_FINISHED = "finished"
finished = false
logicFlow?: LogicFlow;
constructor(meta: INodeDefine<IcustomizedLoopConifg>) {
super(meta)
if (meta.children) {
//通过portId关联子流程的开始跟结束节点，端口号对应节点号
//此处的children是被引擎转换过处理的
this.logicFlow = new LogicFlow({ ...meta.children, id: meta.id }, undefined)
//把子编排的出口，挂接到本地处理函数
const outputPortMeta = this.meta.outPorts?.find(
port=>port.name === CustomizedLoop.PORT_OUTPUT
)
if(outputPortMeta?.id){
this.logicFlow?.jointers?.getOutput(outputPortMeta?.name)?.connect(
this.oneOutputHandler
)
}else{
console.error("No output port in CustomizedLoop")
}
const finishedPortMeta = this.meta.outPorts?.find(
port=>port.name === CustomizedLoop.PORT_FINISHED
)
if(finishedPortMeta?.id){
this.logicFlow?.jointers?.getOutput(finishedPortMeta?.id)?.connect(
this.finisedHandler
)
}else{
console.error("No finished port in CustomizedLoop")
}
} else {
throw new Error("No implement on CustomizedLoop meta")
}
}
@Input()
inputHandler = (inputValue?: unknown, context?:unknown) => {
let count = 0
if (this.meta.config?.fromInput) {
if (!_.isArray(inputValue)) {
console.error("Loop input is not array")
} else {
for (const one of inputValue) {
//转发输入到子编排
this.getInput()?.push(one, context)
count++
//如果子编排调用了结束
if(this.finished){
break
}
}
}
} else if (_.isNumber(this.meta.config?.times)) {
for (let i = 0; i < (this.meta.config?.times || 0); i++) {
//转发输入到子编排
this.getInput()?.push(, context)
count++
//如果子编排调用了结束
if(this.finished){
break
}
}
}
//如果子编排中还没有被调用过finished
if(!this.finished){
this.next(count, CustomizedLoop.PORT_FINISHED, context)
}
}
getInput(){
return this.logicFlow?.jointers?.getInput(CustomizedLoop.PORT_INPUT)
}
oneOutputHandler = (value: unknown, context?:unknown)=>{
//输出到响应端口
this.output(value, context)
}
finisedHandler = (value: unknown, context?:unknown)=>{
//标识已调用过finished
this.finished = true
//输出到响应端口
this.next(value, CustomizedLoop.PORT_FINISHED, context)
}
output = (value: unknown, context?:unknown) => {
this.next(value, CustomizedLoop.PORT_OUTPUT, context)
}
}
基础的逻辑编排引擎，基本全部介绍完了，清楚了节点之间的编排机制，是时候定义节点的连线规则了。
节点的连线规则
一个节点，是一个对象。有状态，有副作用。有状态的对象没有约束的互连，是非常危险的行为。
这种情况会面临一个诱惑，或者说用户自己也分不清楚。就是把节点当成无状态对象使用，或者直接认为节点就是无状态的，不加限制的把连线连到某个节点的入口上。
比如上面计算学生总分例子，可能会被糊涂的用户连成这样：
这种连接方式，直接造成收集数组节点无法正常工作。
逻辑编排之所以直观，在于它把每一个个数据流通的路径都展示出来了。在一个通路上的一个节点，最好只完成一个该通路的功能。另一个通路如果想完成同样的功能，最好再新建一个对象：
这样两个收集数组节点，就互不干扰了。
要实现这样的约束，只需要加一个连线规则：同一个入端口，只能连一条线。
有了这条规则，节点对象状态带来的不利影响，基本消除了。
在这样的规则下，收集数组节点的入口不能连接多条连线，只需要把它重新设计成如下形式：
一个出端口，可以往外连接多条连线，用于表示并行执行。另一条规则就是：同一个出端口，可以有多条连线。
数据是从左往右流动，所以再加上最后一条规则：入端口在节点左侧，出端口在节点右侧。
所有的连线规则完成了，蛮简单的，编辑器层面可以直接做约束，防止用户输错。
编辑器的实现
编辑器布局
整个编辑器分为图中标注的四个区域。
- ① 工具栏，编辑器常规操作，比如撤销、重做、删除等。
- ② 工具箱（物料箱），存放可以被拖放的元件物料，这些物料是可以从外部注入到编辑器的。
- ③ 画布区，绘制逻辑编排图的画布。每个节点都有自己的坐标，要基于这个对DSL进行扩展，给节点附加坐标信息。画布基于阿里antv X6实现。
- ④ 属性面板，编辑元件节点的配置信息。物料是从编辑器外部注入的，物料对应节点的配置是变化的，所以属性面板内的组件也是变化的，使用RxDrag的低代码渲染引擎来实现，外部注入的物料要写到相应的Schema信息。低代码Schema相关内容，请参考另一篇文章《实战，一个高扩展、可视化低代码前端，详实、完整》
扩展DSL
前面定义的DSL用在逻辑编排解析引擎里，足够了。但是，在画布上展示，还缺少节点位置跟尺寸信息。设计器画布是基于X6实现的，要添加X6需要的信息，来扩展DSL：
export interface IX6NodeDefine {
/** 节点x坐标 */
x: number;
/** 节点y坐标 */
y: number;
/** 节点宽度 */
width: number;
/** 节点高度 */
height: number;
}
// 扩展后节点
export interface IActivityNode extends INodeDefine {
x6Node?: IX6NodeDefine
}
这些信息，足以在画布上展示一个完整的逻辑编排图了。
元件物料定义
工具箱区域②跟画布区域③显示节点时，使用了共同的元素：元件图标，元件标题，图标颜色，这些可以放在物料的定义里。
物料还需要：元件对应的Acitvity名字，属性面板④ 的配置Schema。具体定义：
import { NodeType, IPortDefine } from "./dsl";
//端口定义
export interface IPorts {
//入端口
inPorts?: IPortDefine[];
//出端口
outPorts?: IPortDefine[];
}
//元件节点的物料定义
export interface IActivityMaterial<ComponentNode = unknown, NodeSchema = unknown, Config = unknown, MaterialContext = unknown> {
//标题
label: string;
//节点类型，NodeType在DLS中定义，这里根据activityType决定画上的图形样式
activityType: NodeType;
//图标代码，react的话，相当于React.ReactNode
icon?: ComponentNode;
//图标颜色
color?: string;
//属性面板配置，可以适配不同的低代码Schema，使用RxDrag的话，这可以是INodeSchema类型
schema?: NodeSchema;
//默认端口，元件节点的端口设置的默认值，大部分节点端口跟默认值是一样的，
//部分动态配置端口，会根据配置有所变化
defaultPorts?: IPorts;
//画布中元件节点显示的子标题
subTitle?: (config?: Config, context?: MaterialContext) => string | undefined;
//对应解析引擎里的Activity名称，根据这个名字实例化相应的节点业务逻辑对象
activityName: string;
}
//物料分类，用于在工具栏上，以手风琴风格分组物料
export interface ActivityMaterialCategory<ComponentNode = unknown, NodeSchema = unknown, Config = unknown, MaterialContext = unknown> {
//分类名
name: string;
//分类包含的物料
materials: IActivityMaterial<ComponentNode, NodeSchema, Config, MaterialContext>[];
}
只要符合这个定义的物料，都是可以被注入设计器的。
在前面定义DSL的时候， INodeDefine 也有一个一样的属性是 activityName。没错，这两个activityName指代的对象是一样的。画布渲染dsl的时候，会根据activityName查找相应的物料，根据物料携带的信息展示，入图标、颜色、属性配置组件等。
在做前端物料跟元件的时候，为了重构方便，会把activityName以存在Activity的static变量里，物料定义直接引用，端口名称也是类似的处理。看一个最简单的节点，Debug节点的代码。
Activity代码：
import { Activity, Input, AbstractActivity } from "@rxdrag/minions-runtime"
import { INodeDefine } from "@rxdrag/minions-schema"
//调试节点配置
export interface IDebugConfig {
//提示信息
tip?: string,
//是否已关闭
closed?: boolean
}
@Activity(DebugActivity.NAME)
export class DebugActivity extends AbstractActivity<IDebugConfig> {
//对应INodeDeifne 跟IActivityMaterial的 activityName
public static NAME = "system.debug"
constructor(meta: INodeDefine<IDebugConfig>) {
super(meta)
}
//入口处理函数
@Input()
inputHandler(inputValue: unknown): void {
if (!this.config?.closed) {
console.log(`🪲${this.config?.tip || "Debug"}:`, inputValue)
}
}
}
物料代码：
import { createUuid } from "@rxdrag/shared";
import { debugSchema } from "./schema";
import { NodeType } from "@rxdrag/minions-schema";
import { Debug, IDebugConfig } from "@rxdrag/minions-activities"
import { debugIcon } from "../../icons";
import { DEFAULT_INPUT_NAME } from "@rxdrag/minions-runtime";
import { IRxDragActivityMaterial } from "../../interfaces";
//debug节点物料
export const debugMaterial: IRxDragActivityMaterial<IDebugConfig> = {
//对应Activity的Name
activityName: Debug.NAME,
//Svg格式的表
icon: debugIcon,
//显示标题，工具栏直接多语言化后显示，画布上节点Title的初值是这个，可以通过
//属性面板修改
label: "$debug",
//节点类型，普通的Activity
activityType: NodeType.Activity,
//图标颜色
color: "orange",
//默认端口
defaultPorts: {
inPorts: [
{
id: createUuid(),
name: DEFAULT_INPUT_NAME,
label: "",
},
],
},
//子标题，显示配置用的tip
subTitle: (config?: IDebugConfig) => {
return config?.tip
},
//属性面板Schema
schema: debugSchema,
}
属性面板schema的配置就不展开了，感兴趣的朋友请参考Rxdrag的相关文章。该节点在编辑器中的表现：
编辑器的状态管理
如果纯React应用的话，Recoil是不错的状态管理方案，幻想有一天可能会适配其它UI框架，就使用了对框架依赖较少的Redux作为状态管理工具。
编辑器所有状态：
import { INodeDefine, ILineDefine } from "@rxdrag/minions-schema";
//操作快照
export interface ISnapshot {
//全部节点
nodes: INodeDefine<unknown>[];
//全部连线
lines: ILineDefine[];
//当前选中元素
selected?: string,
}
//编辑器状态
export interface IState {
//是否被修改，该标识用于提示是否需要保存
changeFlag: number,
//撤销快照列表
undoList: ISnapshot[],
//重做快照列表
redoList: ISnapshot[],
//全部节点
nodes: INodeDefine<unknown>[];
//全部连线
lines: ILineDefine[];
//当前选中元素
selected?: string,
//画布缩放数值
zoom: number,
//是否显示小地图
showMap: boolean,
}
编辑器就是围绕这份状态数据做功。建一个单独的类用来操作redux store：
//一个用来操作Redux状态数据的类，可以修改数据，也可以订阅数据的变化
export class EditorStore {
store: Store<IState>
constructor(debugMode?: boolean,) {
this.store = makeStoreInstance(debugMode || false)
}
dispatch = (action: Action) => {
this.store.dispatch(action)
}
//节省篇幅，本类不展开了，详细代码青岛rxdrag代码库查看
//地址：https://github.com/codebdy/rxdrag/blob/master/packages/minions/editor/logicflow-editor/src/classes/EditorStore.ts
...
}
编辑器接口
编辑器被设计成一个React Library，方便其它项目的引用。其接口定义如下：
//主题颜色接口
export interface IThemeToken {
colorBorder?: string;
colorBgContainer?: string;
colorText?: string;
colorTextSecondary?: string;
colorBgBase?: string;
colorPrimary?: string;
}
//逻辑编排编辑器属性
export type LogicFlowEditorProps = {
value: ILogicMetas,
onChange?: (value: ILogicMetas) => void,
//编辑器支持的所有物料
materialCategories: ActivityMaterialCategory<ReactNode>[],
//属性面板用的的空间
setters?: IComponents,
logicFlowContext?: unknown,
//可以被引用的子编排
canBeReferencedLogflowMetas?: ILogicFlowDefine[],
//工具栏，false表示隐藏
toolbar?: false | React.ReactNode,
}
//逻辑编排编辑器对应的React组件
export const LogicMetaEditor = memo((
props: LogicFlowEditorAntd5rProps&{
token: IThemeToken,
}
) => {
...
}}
深度集成的考量
编辑器有时候要跟其它编辑器，比如后端的领域模型编辑器深度集成，共享一套撤销、重做、删除按钮。比如：
这种情况要通过给toolbar属性传入false，把编辑器原来的工具条隐藏掉。另外，要跟领域模型编辑器共用一个工具栏区域，需要在编辑器能在外部控制Redux store里面的内容。
为了实现这样的集成，添加一个上下文，用于下发一个全局的EditorStore。定义一个标签，叫LogicFlowEditorScope，用于限定逻辑编排编辑器的范围，只要是在标签内部，store数据可以随意修改。
import { memo, useMemo } from "react"
import { LogicFlowEditorStoreContext } from "../contexts";
import { EditorStore } from "../classes";
import { useEditorStore } from "../hooks";
//用于创建全局EditorStore，并通过Context下发
const ScopeInner = memo((props: {
children?: React.ReactNode
}) => {
const { children } = props;
const store: EditorStore = useMemo(() => {
return new EditorStore()
}, [])
return (
<LogicFlowEditorStoreContext.Provider value={store}>
{children}
</LogicFlowEditorStoreContext.Provider>
)
})
//编辑器Scope定义
export const LogicFlowEditorScope = memo((
props: {
children?: React.ReactNode
}
) => {
const { children } = props;
//去外层Store
const parentStore = useEditorStore()
return (
//如果外层已经创建Scope，那么直接用外层的，反之新建一个
parentStore ?
<>{children}</>
:
<ScopeInner>
{children}
</ScopeInner>
)
})
这个LogicFlowEditorScope会在逻辑编辑器的根部放置一个，如果编辑器外部没有定义，就是用这个默认的。如果外部已经定义了，那么就用外部的。
领域模型编辑器集成的时候，只要在工具栏外层放置一个LogicFlowEditorScope，就可以方便的操作编辑器里的内容了：
import { memo } from "react"
import { UmlEditorInner, UmlEditorProps } from "./UmlEditorInner"
import { RecoilRoot } from "recoil"
import { LogicFlowEditorScope } from "@rxdrag/minions-logicflow-editor"
//领域模型UML编辑器部分
export const UmlEditor = memo((props: UmlEditorProps) => {
return <RecoilRoot>
//外层放置逻辑编排的Scope
<LogicFlowEditorScope>
<UmlEditorInner {...props} />
</LogicFlowEditorScope>
</RecoilRoot>
})
...
//创建逻辑编排编辑起的时候，toolbar赋值false
<LogicFlowEditorAntd5
materialCategories={activityMaterialCategories}
locales={activityMaterialLocales}
token={token}
value={value?.logicMetas || EmpertyLogic}
logicFlowContext={logicFlowContext}
onChange={handleChange}
setters={{
SubLogicFlowSelect,
}}
canBeReferencedLogflowMetas={canBeReferencedLogflowMetas}
//隐藏默认工具栏
toolbar={false}
/>
...
前端逻辑编排
前端逻辑编排主要编排的内容是组件的联动，组件数据的填充以及服务端数据的获取及存储等内容。这些内容，就是一般被称作业务逻辑的内容。
通常的实现方式中，这些业务逻辑会与ui组件紧密结合，甚至很多被写在了组件内部。想让逻辑编排的适应能力更强，最好能够把这些内容从组件中剥离出来，形成独立的业务层，尽可能压缩UI层的厚度，UI层就像美女，瘦的总是比胖的好看些，如果不认同的话欢迎留言讨论。
像React这样的框架，组件有自己的生命周期管理，在低代码项目中，如果业务逻辑跟组件搅在一起，业务逻辑就跟组件的生命周期也搅在一起了，处理这样的代码，是非常痛苦的过程。
所以，有人喜欢mobx，可以不用过度关注React的生命周期。
mobx是把双刃剑，有有点也有缺点。如果用mobx做低代码平台，基本不好兼容现有的组件库，所有组件都要重新封装一层，就像formily做的那样。这样的方式不能说不好，只是小编不喜欢。就像姑娘，自己不喜欢的姑娘照样很多人抢，自己梦寐以求的姑娘，别人可能敬而远之。或许，这就是生活吧。百花齐放的世界里，可以肆意选择的感觉挺好。
组件控制器
想要ui层变瘦，就不要在组件内部加太多的业务逻辑，只是通过组件自身的props控制组件的行为，只需在组件外层加一个控制器，来控制组件的props就好。
加入控制器以后，组件之间的交互联动，就变成了控制器之间的交互了，并且可以通过逻辑编排来编排这些控制器。
不同的实现方式，有不同的优点跟缺点。逻辑编排也一样，他可能并不适合所有的业务逻辑，对于CRUD这样简单的业务，逻辑编排反而显得笨重了。
不需要逻辑编排的场景，可能需要给组件配置一个其它的控制器。所以，组件控制器可以遵循相同的接口，并且可以有不同的实现：
用了不少继承，这里也没必要争论该用继承还是该用组合，代码量不大，习惯了这样写。看不惯的朋友，可以用组合再实现一遍。
控制器IController接口实现了两个接口：属性控制器（IPropsController）跟变量控制器（IVariableController）。属性控制器用来管理组件的属性，这里的属性只是数值类型的属性，不包含函数类型的属性（也就事件），事件需要单独处理。变量控制器用来管理控制器的自定义变量，有点类似类的成员变量。也是不同控制器之间交换数据的重要手段。
不管是属性控制器还是变量控制器，都实现了相应的订阅（subscribe）方法，用于监听其变化，有点mobx之类的Proxy感觉，控制器监听到了Props的变化，会通过自身的subscribeToPropsChange方法发布出去，用于更新组件。要注意的是，属性控制器（IPropsController)的订阅方法订阅的是单个属性的变化，而这里订阅的是全部属性的变化，这里实现的内部使用了属性控制器（IPropsController)的subscribeToPropChange方法。
AbstractController是所有Controller的基类，封装了控制器的通用逻辑。
下面的三个控制器分别是：
- 逻辑编排控制器(LogicFlowController)，顾名思义，用逻辑编排实现控制器的业务逻辑。这是框架内置控制器，
- 脚本控制器(ScriptController)，用JS脚本实现控制器的业务逻辑。这也是框架内置控制器。
- 简单控制器（SimpleController），本控制器不是框架内置的，属于自定义控制器，放在了代码的Expamle部分（代码中可能叫ShortcutController）。因为有些简单的CRUD操作，几不需要编排控制器，也不需要脚本控制器，就定义这些简易控制器。还可以根据需要定义其它控制器，并把这些控制器注入到编辑器跟解析引擎。
控制器在Page Schema中的配置
前端逻辑编排的应用场景是低代码，低代码平台中，用DSL（通常是JSON Schema）来描述一个页面。这里以RxDrag的Schema定义为例，介绍控制器的配置，逻辑编排部分可以独立于Rxdrag运行，您可以用类似的方式整合到其它低码平台的Schema中。
RxDrag中组件元数据的定义：
export interface INodeMeta<
IField = unknown,
INodeController = unknown
> {
componentName: string;
props?: {
[key: string]: unknown;
};
'x-field'?: IField;
//节点控制器，逻辑编排用
'x-controller'?: INodeController;
//锁定子控件
locked?: boolean;
//自己渲染，引擎不渲染
selfRender?: boolean;
}
泛型属性x-controller是控制器的DSL，在我们这里给它这样一个定义：
import { ILogicFlowDefine } from "@rxdrag/minions-schema";
//控制器变量定义
export interface IVariableDefineMeta {
//变量标识
id: string;
//变量名称
name: string;
//变量默认值
defaultValue?: unknown;
}
//控制器元数据定义，相当于控制器配置的DSL
export interface IControllerMeta {
//控制器标识
id: string;
//控制器类型，因为控制器可以注入很多种，类型不固定，这里不能用枚举，只能用字符串
controllerType?: string;
//是否全局，配置控制器的可见范围
global?: boolean;
//控制器名称
name?: string;
}
//逻辑编排控制器
export interface ILogicFlowControllerMeta extends IControllerMeta {
//组件事件对应的逻辑编排，通过name与组件的事件建立联系
events?: ILogicFlowDefine[];
//控制器的交互，相当于子编排，可以被其他编排调用
reactions?: ILogicFlowDefine[];
//控制器的变量
variables?: IVariableDefineMeta[];
}
//脚本控制器
export interface IScriptControllerMeta extends IControllerMeta {
//脚本代码
script?: string
}
只给出了逻辑编排控制器跟脚本控制器DSL的定义，简易控制器跟框架实现关系不大，属于自定义控制器，这里就不深入展开了。
控制器与组件的绑定
低代码一般两种方式渲染页面：1、有一个渲染引擎，渲染页面DSL（通常是JSON）；2、生成前端代码。
作者自己的低代码平台还没做出码，这里只讨论第一种情况。
低代码渲染引擎以组件节点为单位，递归渲染页面Schema：根据componentName拿到组件实现函数，并渲染。当渲染引擎解析到字段x-controller时，就在外面套一个高阶组件withController，在这个高阶组件里完成控制器与目标组件的绑定。
渲染引擎相关代码：
export const ComponentView = memo((
props: ComponentViewProps
) => {
const { node, ...other } = props
//拿到组件定义函数
const com = usePreviewComponent(node.componentName)
//根据需要包装组件
const Component = useMemo(() => {
return com &&
withController(//通过高阶组件，绑定控制器与目标组件
com,
node["x-controller"] as ILogicFlowControllerMeta,
node.id,
)
}, [com, node]);
...
return (
Component &&
(
node.children?.length ?
<Component {...node.props} {...other}>
{
!node.selfRender && node.children?.map(child => {
return (<ComponentView key={child.id} node={child} />)
})
}
</Component>
: <Component {...node.props} {...other} />
)
)
})
高阶组件内部的绑定代码：
export function withController(WrappedComponent: ReactComponent, meta: IControllerMeta | undefined, schemaId: string): ReactComponent {
if (!meta?.id || !meta?.controllerType) {
return WrappedComponent
}
return memo((props: any) => {
const [changedProps, setChangeProps] = useState<any>()
const [controller, setController] = useState<IController>()
//运行时引擎，通过它来创建控制器
const runtimeEngine = useRuntimeEngine();
//拿到controller对应的唯一标识
const controllerKey = useControllerKey(meta, schemaId)
const handlePropsChange = useCallback((name: string, value: any) => {
setChangeProps((changedProps: any) => {
return ({ ...changedProps, [name]: value })
})
}, [])
useEffect(() => {
if (meta?.controllerType && runtimeEngine && controllerKey) {
//创建控制器
const ctrl = runtimeEngine.getOrCreateController(meta, controllerKey)
//初始化
ctrl.init(controllers, logicFlowContext);
//订阅属性变化
const unlistener = ctrl?.subscribeToPropsChange(handlePropsChange)
setController(ctrl)
return () => {
ctrl?.destory()
unlistener?.()
}
}
}, [controllerKey, handlePropsChange, runtimeEngine])
const newProps = useMemo(() => {
//组装最新的Props，注意，组件的事件也在这里完成的绑定
return { ...props, ...controller?.events, ...changedProps }
}, [changedProps, controller?.events, props])
return (
controller
//通过上下文下发Controller，这样可以在组件内拿到Controller
//只是应对特例，因为只有极少情况需要在组件内部调用Controller
? <ControllerContext.Provider value={controller}>
//最新的Props传入目标组件
<WrappedComponent {...newProps} />
</ControllerContext.Provider>
: <>Can not creat controller </>
)
})
控制器的可见范围
上面只完成了一个控制器，并且这个控制器是孤立的，并没有跟其他控制器发生关系。想要发生关系，控制器就不能是孤立的，需要相互认识（一方知道另一方的引用，或者一方知道另一方的查找方法）。
让控制器相互知道的方式有：
1、全部控制器注册到一个全局变量里面，所有控制器都能访问这个变量；
2、通过Context下发控制器，子组件的控制器能访问所有的父组件的控制器，父组件的控制器访问不了子控件的控制器。
3、前两种方式的组合，默认通过第二种方式传递控制器，如果控制器在设计其中被配置为全局，则按照第一种方式传递。
第一种方式已经很直观了，为什么还要考虑第二种跟第三种？或者说压根忘掉第二种，直接用第一种。
答案是低代码平台的组件设计是否支持，就是跟低代码平台的组件设计理念相关。作者本人是业余选手，项目经验不多，不知道哪种方案更合理。就把可能的情况罗列一下，有观点朋友欢迎留言给点意见，不胜感激。
原子化组件设计
不同的低代码平台，组件的设计粒度是不一样的。作者自己的的低码平台，提倡的是原子化的组件设计，很多组件的设计粒度很细。这种情况下，不可能每个组件都附加一个控制器，很多组件只是用来调整页面布局，根本不需要控制器。
所以，在前端配置页面，加了控制器选择组件，用于指示给组件启用哪种类型的控制器：
这个单选按钮组，是可以不选的，不选时意味着不需要给组件配置控制器。
原子化组件设计，组件的粒度很细，细到列表也是有各种组件组合而成，列表内的组件是可以随意拖入的，比如下面这个列表行中的“编辑”、“删除”按钮：
这些行组件是根据数据行记录而动态创建的，原子化的设计对这些列表没有太多的封装，所以无法从全局拿到这些动态创建组件的控制器。
在这种情况下，通过context下发控制器是个不错的选择，所有子组件的控制都可以访问父组件控制器。部分需要全局共享的控制器，就在界面中配置为全局。这两种方式结合，基本可以满足控制器之间的交互需求。
高阶组件withController的实现代码变成：
import { ReactComponent } from "@rxdrag/react-shared"
import { memo, useCallback, useEffect, useMemo, useState } from "react"
import { ControllerContext, ControllersContext } from "../contexts"
import { useControllers } from "../hooks/useControllers"
import { Controllers, IController, ILogicFlowControllerMeta as IControllerMeta } from "@rxdrag/minions-runtime-react"
import { useLogicFlowContext } from "../hooks/useLogicFlowContext"
import { useRuntimeEngine } from "../hooks/useRuntimeEngine"
import { useControllerKey } from "../hooks/useControllerKey"
export function withController(WrappedComponent: ReactComponent, meta: IControllerMeta | undefined, schemaId: string): ReactComponent {
if (!meta?.id || !meta?.controllerType) {
return WrappedComponent
}
return memo((props: any) => {
//发生变化的props
const [changedProps, setChangeProps] = useState<any>()
//组件自身的控制器
const [controller, setController] = useState<IController>()
//所有上级控制器+全局控制器
const controllers = useControllers()
//管理控制器的运行时引擎
const runtimeEngine = useRuntimeEngine();
//控制器唯一标识，根据层级关系跟控制器本身ID组合产生，用于唯一标识一个控制器
const controllerKey = useControllerKey(meta, schemaId)
//处理控制器中的props变化
const handlePropsChange = useCallback((name: string, value: any) => {
setChangeProps((changedProps: any) => {
return ({ ...changedProps, [name]: value })
})
}, [])
useEffect(() => {
if (meta?.controllerType && runtimeEngine && controllerKey) {
//给组件创建控制器
const ctrl = runtimeEngine.getOrCreateController(meta, controllerKey)
//初始化控制器
ctrl.init(controllers);
//监听props变化
const unlistener = ctrl?.subscribeToPropsChange(handlePropsChange)
setController(ctrl)
return () => {
ctrl?.destory()
unlistener?.()
}
}
}, [controllerKey, controllers, handlePropsChange, runtimeEngine])
//把该组件可见的控制器打包成一个数组
const newControllers: Controllers = useMemo(() => {
return controller ? { ...controllers, [controller.id]: controller } : controllers
}, [controller, controllers])
//最新的props
const newProps = useMemo(() => {
return { ...props, ...controller?.events, ...changedProps }
}, [changedProps, controller?.events, props])
return (
controller
? <ControllersContext.Provider value={newControllers}>
<ControllerContext.Provider value={controller}>
<WrappedComponent {...newProps} />
</ControllerContext.Provider>
</ControllersContext.Provider>
: <>Can not creat controller </>
)
})
}
这种实现方式其实已经足够灵活了，能够应对几乎常见的需求，但是，比起后面的粗粒度组件设计，用户体验确实要差一些，用户需要理解的概念有点多，需要配置的东西也有点多。
当然，实际的项目中，从列表外面访问列表行内组件的场景几乎没有，所以只要把外围的组件控制器放入全局，供列表内组件使用，也是可以的。这样，就不需要context了，但是这样应对不了列表套列表的情况。或许列表套列表的情况不多吧。
小编也想用户体验更好些，但是做起来就不由自主的兼顾了更多的灵活性，可能把最终用户当成自己了吧。后面可能需要更多的在项目中磨练自己，有跟作者方向一致的朋友，欢迎联系作者，我们可以一起做一些项目相互学习、共同成长。
粗粒度组件设计
粗粒度组件的设计，会带来非常良好的用户体验。
这是跟原子化组件完全不同的设计理念，每个组件的功能比较多，一个页面仅需要非常少的组件就能完成。
既然组件较少，每个组件配置一个控制器（或者类似控制器的东西），把这些控制器设置为全局，逻辑编排的时候，这些全局控制器可以相互调用，直观方方便。
粗粒度的组件，同样会有列表，列表要如何处理呢？
可以把列表做成功能全面的组件，行内组件以卡槽的方式插入列表。这种情况下，自然的会假设没有编排列表套列表这样的变态需求。
逻辑编排编辑器设计的时候，可以直接从物料箱（工具箱）选择组件控制器，进行编排。
在上文中，我们只定义了基础的IController接口，实现了基础的抽象类AbstractController。AbstractController下面派生出来的子类，不管是逻辑编排控制器还是脚本控制器，都没有实现太多的业务逻辑，而是把业务逻辑留给了逻辑编排或者脚本来完成。
既然组件的粒度变粗了，必然是包含了某些业务逻辑。可以把这些逻辑重新还给组件，让每个组件或者组件的控制器包含自己的业务逻辑。
粗粒度组件更友好的编排方式
控制器，是软件设计实现层面的东西，最终用户可能不需要关心这样的实现细节。控制器这个概念的添加，无疑会增加用户的理解成本。对用户来讲，最直观的理解对象是组件。
在逻辑编排中，如果以组件而不是控制器为编排对象，会更加有利于用户的理解，比如：
图中对话框的这个元件节点，是不是更直观，更容易理解？
在我们已经设计的架构体系里，能实现这样的效果？
当然可以，并且可以继续用控制器（通用控制器或者特殊控制器都行），加入有个通用控制器叫DefaultController，它是AbstractConroller的一个子类，实现了常用的控制器功能。可以为对话框组件，定制一个单独的元件节点，节点保有组件控制器DefaultController的一个引用就可以：
给DialgoActivity配置上相应物料，就可以以组件的面貌参与逻辑编排了，虽然内部基于控制器IController实现，但用户是感知不到IController存在的。元件物料定义：
//上下文中的控制器参数
export interface IControllerEditorContextParam {
//所有能访问的控制器
controllers?: ILogicFlowControllerMeta[],
//当前组件控制器
controller?: ILogicFlowControllerMeta,
}
export const dialogMaterial: IRxDragActivityMaterial<IPropConfig, IControllerEditorContextParam> = {
icon: dialogIcon,
label: "对话框",
activityType: NodeType.Activity,
defaultPorts: {
inPorts: [
{
id: createUuid(),
name: DialogAtivity.PORT_OPEN,
label: "打开",
},
],
outPorts: [
{
id: createUuid(),
name: DialogAtivity.PORT_CLOSE,
label: "关闭",
},
],
},
//属性面板Schema
schema: dialogSchema,
//副标题显示具体哪个对话框
subTitle: (config?: IPropConfig, context?: IControllerEditorContextParam) => {
const controllerName = context?.controllers?.find(controler => controler.id === config?.param?.controllerId)?.name
return controllerName ? (controllerName + "/" + (config?.param?.prop || "")) : ""
},
activityName: DialogAtivity.NAME,
}
DialogActivity的定义大致如下（作者没做粗粒度组件，故以下代码不来自真实代码，只是示意）：
export interface IControllerContext {
controllers: Controllers,
}
export interface IControllerParam {
controllerId?: string
}
export interface IDialogConfig {
param?: IControllerParam
}
@Activity(DialogActivity.NAME)
export class DialogActivity extends AbstractActivity<IDialogConfig> {
public static NAME = "dialog"
public static PORT_OPEN = "open"
public static PORT_CLOSE = "close"
//组件控制器
controller: IController
constructor(meta: INodeDefine<IDialogConfig>, context?: IControllerContext) {
super(meta, context)
if (!meta.config?.param?.controllerId) {
throw new Error("ReadProp not set controller id")
}
const controller = context?.controllers?.[meta.config?.param?.controllerId]
if (!controller) {
throw new Error("Can not find controller")
}
this.controller = controller
}
@Input(DialogActivity.PORT_OPEN)
openHandler = () => {
this.controller.setProp("open", true)
}
@Input(DialogActivity.PORT_CLOSE)
closeHandler = () => {
this.controller.setProp("close", true)
}
}
朋友，读到这里，业务逻辑跟ui层解耦的魅力，您体会到了吗？
前端逻辑编排编辑器
Rxdrag项目中，前端编辑器的项目构成：
整个逻辑编排功能分为两个顶层包：
- minions，包含逻辑编排运行时、设计器跟DSL定义(schema)，本包不依赖antd，就是说如果你的项目不想引入antd或者说antd的版本跟作者不一样，可以使用这个包，但不能使用下面另一个包。
- minions-antd5，跟antd5相关的部分，全部都在这个包里，这个包大部分都是设计器相关的东西，运行时相关的东西仅包含Activity的定义。
具体每个包的详细解释：
minions
-editor 编辑器相关，可能会依赖runtime包。
-controller-editor 控制器编排编辑器。包含了对组件控制器的编排，主要用于前端，基于下面的logicflow-editor实现。
-logicflow-editor 最基础的逻辑编排编辑器，不包含前端控制器编排相关内容。后端编排编辑器可以基于这个实现。
-runtime 运行时，逻辑编排的解析引擎相关，不依赖于editor包的任何东西。
-activities 预定义的Activities，也就是元件节点的实现逻辑。比如循环、条件等
-runtime-core 逻辑编排解析引擎核心包，react无关。
-runtime-react 逻辑编排解析引擎react相关部分，包括控制器相关内容。
minions-antd5,
-controller-editor-antd5 控制器编排编辑器，依赖antd5，依赖logicflow-editor-antd5
-logicflow-editor-antd5 普通编排编辑器，依赖antd5
-minions-react-antd5-activites antd5相关的Activities
-minions-react-materials 物料定义，这些物料的实现依赖antd5和rxdrag低代码引擎部分。
具体代码实现内容不少，感兴趣的话自行翻代码库看看吧，篇幅所限，无法进一步展开了。
控制器的注入
本节内容只是针对原子化组件低代码平台的，并未考虑粗粒度组件，粗粒度组件不需要注入控制器，只需要使用DefaultController就可以。
低代码平台中，逻辑编排的配置是以属性配置组件的形式出现的：
这些控制器是可以注入的，这个跟具体低代码平台的实现机制有关，这里只是提一下思路，根本文主题关系不大，就不详细展开了。
后端逻辑编排
后端逻辑编排的设计器使用的是logicflow-editor-antd5这个包，编辑器部分的实现跟前端逻辑编排基本一致。本节主要讨论后端解析引擎的实现。
前端定义元件节点物料，把物料注入逻辑编排编辑器。后端定义元件实现逻辑（Activity），把Activity注入后端编排解析引擎。节点物料依赖Activity，通过activityName关联。
逻辑编排编辑器生成产物是JSON格式的编排描述数据，后端引擎消费这个JSON，转化成具体的执行逻辑。
逻辑编排解析引擎的代码量并不大，相当于把前面讨论的Typescript实现转译为一份golang的实现。项目代码结构：
这是一个golang library，可以在其他golang项目中被引用，作者在自己的低代码平台中，使用了这个库。代码结构关键部分：
- activities，预定义元件的实现逻辑。
- dsl，就是上面Typescript定义的那份DSL，这里转译成Golang。
- example，该库使用例子，后面会实现，现在还没有。
- runtime，逻辑编排解析引擎。
DSL转译
//端口定义
type PortDefine struct {
//ID
Id string `json:"id"`
//名称
Name string `json:"name"`
//标题
Label string `json:"label"`
}
//线的连接点
type PortRef struct {
//节点ID
NodeId string `json:"nodeId"`
//端口ID
PortId string `json:"portId"`
}
//连线定义
type LineDefine struct {
Id string `json:"id"`
//源节点
Source PortRef `json:"source"`
//目标节点
Target PortRef `json:"target"`
}
//节点定义
type NodeDefine struct {
Id string `json:"id"`
//名称
Name string `json:"name"` //嵌入编排，端口转换成子节点时使用
//节点类型，对应Typescript的枚举
Type string `json:"type"`
//元件对应Activity名称
ActivityName string `json:"activityName"`
//标题
Label string `json:"label"`
//配置
Config map[string]interface{} `json:"config"`
//入端口
InPorts []PortDefine `json:"inPorts"`
//出端口
OutPorts []PortDefine `json:"outPorts"`
//子节点，嵌入式节点用，比如自定义循环节点、事务节点
Children LogicFlowMeta `json:"children"`
}
//一段逻辑编排
type LogicFlowMeta struct {
//所有节点
Nodes []NodeDefine `json:"nodes"`
//所有连线
Lines []LineDefine `json:"lines"`
}
//子编排，可以被其它编排调用
type SubLogicFlowMeta struct {
//组合一段编排数据
LogicFlowMeta
//用于调用寻址
Id string
}
就是简单定义，没有什么需要特殊解释的。
Activity的实现
在前端编排引擎的实现中，我们用了放射中的注解来收集Ativity跟它的端口处理函数。golang中并没有注解，并且也没有办法通过Struct的名字拿到Struct。这部分，就不得不做一些变通的处理。
第一次尝试，充分利用泛型，使用工厂方法，在runtime模块定义一个注册工厂方法的函数：
//注册工厂方法，用于创建Activity实例
func RegisterActivity(name string, factory interface{}) {
activitiesMap.Store(name, factory)
}
//工厂方法的泛型
func NewActivity[Config any, T Activity[Config]](meta *dsl.ActivityDefine) *T {
var activity T
activity.GetBaseActivity().Init(meta)
return &activity
}
Activity相应的实现方式：
type DebugConfig struct {
Tip string `json:"tip"`
Closed bool `json:"closed"`
}
type DeubugActivity struct {
BaseActivity runtime.BaseActivity[DebugConfig]
}
func init() {
//注册工厂函数
runtime.RegisterActivity(
"debug",
//把泛型定义的工厂方法实例化为具体方法
runtime.NewActivity[DebugConfig, DeubugActivity],
)
}
func (d* DeubugActivity) GetBaseActivity() *runtime.BaseActivity[DebugConfig] {
return &d.BaseActivity
}
这个实现方式能够正常运行，并且引擎代码相对简单。但是，实现一个Activity的代码看起来有些复杂，增加了用户的心智负担，还是希望Activity的定义能够更简单些。
最后，放弃了泛型，具体类型由引擎通过反射来识别，注册时只传入一个Activity实例，Activity的复杂度，转移到了引擎内部：
type DebugConfig struct {
Tip string `json:"tip"`
Closed bool `json:"closed"`
}
type DebugActivity struct {
Activity runtime.Activity[DebugConfig]
}
func init() {
runtime.RegisterActivity(
"debug",
DebugActivity{},
)
}
是不是看起来简单多了？
端口与端口处理函数的绑定
golang没有注解，不能像Typescript那样，通过注解把端口跟端口处理函数关联起来。但是golang有反射，通过一个变量，能够拿到变量的类型，并且创建另一个同类型的实例。通过方法名称，能够拿到并调用这个实例上的方法。所以，不需要注解，可以直接通过端口名字调用对应端口处理函数，只要端口名字跟端口处理函数的名字一致（首字母大小写不敏感），这些都是在框架内完成的。
上面Debug对应的input端口处理函数，不需要任何额外处理，直接这么写，框架能自动完成绑定，下面这个函数会被自动绑定到input入端口：
func (d *DebugActivity) Input(inputValue any, ctx context.Context) {
config := d.Activity.GetConfig()
...
}
编排引擎的详细实现原理这里就不展开了，感兴趣的话请参考上面的前段编排引擎部分吧。
对接函数参数的处理
在前端，一个编排对应的是组件的一个事件，事件是一个函数，事件的参数会以数组的形式传给入口的inputValue，使用的时候用数组拆分元，把参数拆出来使用：
组件函数的参数，没有名字信息不能转成map：
//这种方式使用函数，参数没有名字信息，只有顺序信息
(...args: unknown[]) => inputOne.push(args)
在后端，作者把一个逻辑编排对应一个graphql接口（field），它的参数是map，没有顺序信息，不能转成数组，只能用对象拆分元件来拆分参数：
是的，你没看错，同样是参数分解，前后端不一致了，可能会给用户造成困扰。
目前想了一个折中的办法，不管是前端编排还是后端编排，都建一个名字是“参数分解”的元件，只是后端是基于对象拆分实现，前端是基于数组拆分实现。
后端的逻辑编排的集成
在低代码平台中，后端的逻辑编排要跟后端其它服务集成在一起，有两种实现方式：
- 逻辑编排是单独的服务
- 逻辑编排跟模型服务集成在一起
这两种实现方式，小编倾向于后者。理由有两个：
- 逻辑编排独立成一个微服务，更加了事务编排的难度
- 逻辑编排独立成微服务，不方便给编排添加后面说的类型系统。
展望未来
逻辑编排的介绍接近尾声了，虽然洋洋洒洒2w字，感觉还是浅尝辄止，很多内容没有深入下去，实际代码相比文章还是要复杂些，感兴趣的朋友欢迎翻阅代码并交流。
文中并没有涉及逻辑编排中的一个重要内容，类型约束。有了类型约束，用户编排的效率会提高很多，出错的概率会降低很多。类型可以编辑器增加智能提示，输入限制，给解析引擎的类型转换提供支持。
接下来，会以UML类图的形式，给自己的低代码平台提供领域模型。这个领域模型，贯穿模型前后端，并衍生出一套类型系统，附加到低代码的各个部分，自然也会附加到逻辑编排这部分。类型系统的思路，来自大佬徐飞的一篇文章。
今年写了两篇长文，一篇是《实战，一个高扩展、可视化低代码前端，详实、完整》还有一篇就是本文。上一篇重点在可视化编辑部分，本篇重点是逻辑编排。还欠缺页面的数据模型部分，会在不远的将来补上。
总结
本文主要写了数据流驱动的逻辑编排运行原理、编辑器、解析引擎等内容，涵盖前端编排跟后端编排。虽然质量不怎么样，但是却是用心在写，前后花了一个星期的时间。希望能给需要的朋友一点帮助或者启发，价值便是我的动力所在。
有不同意见的朋友欢迎留言讨论，没事找事的朋友，欢迎来战。
感谢
感谢板砖团队的MyBricks产品，它提供了宝贵的思路，让Rxdrag的逻辑编排部分得以完成。
感谢网友陌路及其团队成员提供的支持，每次迷茫的时候，跟他们讨论一下，总会有一种豁然开朗的感觉。
感谢网友青铜提供支持，正是因为他的鼎力相助，才能让我这个环境小白成功的做了一个Monorepo项目。
感谢一致以来关注跟支持我的朋友，朋友们的支持给了我莫大的鼓励，希望在未来的日子里，我们还能相互陪伴一起走的更远。
最后，感谢CCTV，虽然不知道它做了什么，但是总觉还是要提前感谢一下，说不定它某一天真能做些什么。
希望在以后的日子里，帮到的人越来越多。也希望以后文章的感谢列表越来越长。