前一段时间写过一篇文章《 实战，一个高扩展、可视化低代码前端，详实、完整 》，得到了很多朋友的关注。 其中的逻辑编排部分过于简略，不少朋友希望能写一些关于逻辑编排的内容，本文就详细讲述一下逻辑编排的实现原理。 逻辑编排的目的，是用最少甚至不用代码来实现软件的业务逻辑，包括前端业务逻辑跟后端业务逻辑。本文前端代码基于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，没有顺序信息，不能转成数组，只能用对象拆分元件来拆分参数： 是的，你没看错，同样是参数分解，前后端不一致了，可能会给用户造成困扰。 目前想了一个折中的办法，不管是前端编排还是后端编排，都建一个名字是“参数分解”的元件，只是后端是基于对象拆分实现，前端是基于数组拆分实现.

后端的逻辑编排的集成

在低代码平台中，后端的逻辑编排要跟后端其它服务集成在一起，有两种实现方式:

• 逻辑编排是单独的服务

• 逻辑编排跟模型服务集成在一起

这两种实现方式，小编倾向于后者。理由有两个:

1. 逻辑编排独立成一个微服务，更加了事务编排的难度
2. 逻辑编排独立成微服务，不方便给编排添加后面说的类型系统。

展望未来

逻辑编排的介绍接近尾声了，虽然洋洋洒洒2w字，感觉还是浅尝辄止，很多内容没有深入下去，实际代码相比文章还是要复杂些，感兴趣的朋友欢迎翻阅代码并交流。 文中并没有涉及逻辑编排中的一个重要内容，类型约束。有了类型约束，用户编排的效率会提高很多，出错的概率会降低很多。类型可以编辑器增加智能提示，输入限制，给解析引擎的类型转换提供支持。 接下来，会以UML类图的形式，给自己的低代码平台提供领域模型。这个领域模型，贯穿模型前后端，并衍生出一套类型系统，附加到低代码的各个部分，自然也会附加到逻辑编排这部分。类型系统的思路，来自大佬徐飞的一篇文章。 今年写了两篇长文，一篇是《实战，一个高扩展、可视化低代码前端，详实、完整》还有一篇就是本文。上一篇重点在可视化编辑部分，本篇重点是逻辑编排。还欠缺页面的数据模型部分，会在不远的将来补上.

总结

本文主要写了数据流驱动的逻辑编排运行原理、编辑器、解析引擎等内容，涵盖前端编排跟后端编排。虽然质量不怎么样，但是却是用心在写，前后花了一个星期的时间。希望能给需要的朋友一点帮助或者启发，价值便是我的动力所在。 有不同意见的朋友欢迎留言讨论，没事找事的朋友，欢迎来战.

感谢

感谢板砖团队的MyBricks产品，它提供了宝贵的思路，让Rxdrag的逻辑编排部分得以完成。 感谢网友陌路及其团队成员提供的支持，每次迷茫的时候，跟他们讨论一下，总会有一种豁然开朗的感觉。 感谢网友青铜提供支持，正是因为他的鼎力相助，才能让我这个环境小白成功的做了一个Monorepo项目。 感谢一致以来关注跟支持我的朋友，朋友们的支持给了我莫大的鼓励，希望在未来的日子里，我们还能相互陪伴一起走的更远。 最后，感谢CCTV，虽然不知道它做了什么，但是总觉还是要提前感谢一下，说不定它某一天真能做些什么。 希望在以后的日子里，帮到的人越来越多。也希望以后文章的感谢列表越来越长.

最后此篇关于前、后端通用的可视化逻辑编排的文章就讲到这里了,如果你想了解更多关于前、后端通用的可视化逻辑编排的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。