lowcode-engine 协议栈简介三大协议如何统一低代码的搭建、物料与生态【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine本文围绕 lowcode-engine 官方文档《协议栈简介》展开完整覆盖“什么是低代码协议、为什么需要协议、协议的作用”三大核心脉络并结合当前仓库中的物料解析material-parser、渲染器renderer-core / react-renderer与出码引擎code-generator等真实源码实现说明三份协议是如何在工程侧被落地消费、从而保障低代码领域标准化与生态流通的。读完后你将理解 lowcode-engine 协议栈的整体设计思想并能定位到仓库中每份协议对应的实现模块与数据结构。一、什么是低代码协议三份协议构成体系基石lowcode-engine 的低代码引擎体系基于三份协议来构建《低代码引擎搭建协议规范》定义搭建产物应用、页面、区块、组件的 Schema 结构约束搭建编辑器的输出以及渲染模块、出码模块的输入《低代码引擎物料协议规范》定义物料业务组件、区块、模板的目录结构、API 规范与组件描述协议configure/snippets 等《低代码引擎资产包协议规范》定义资产包的组织与消费方式。它们保障了低代码领域的标准化成为生态建设和流通的基石。协议与仓库中各模块的对应关系可以这样理解结合源码结构可以推断搭建协议→ 消费端包括渲染模块 packages/react-renderer/src/index.ts 与出码模块 modules/code-generator/src/parser/SchemaParser.ts物料协议→ 生产端是入料模块 modules/material-parser/src/index.ts它自动扫描、解析源码组件产出符合物料协议的 Schema JSON资产包协议→ 物料中心的“npm 式”管理方式统一上传、存储、检索、分发。在 packages/react-renderer/src/index.ts 中可以看到渲染侧通过adapter.setRenderers注册了PageRenderer、ComponentRenderer、BlockRenderer、AddonRenderer、TempRenderer、DivRenderer等渲染器工厂——这正对应搭建协议中“组件结构 / 容器结构”的描述页面Page、区块Block、低代码业务组件Component三类容器分别由独立渲染器消费同一份 Schema体现了协议“将搭建编辑器、渲染模块、出码模块解耦”的设计目标。二、为什么需要协议协议缺失时代的五大痛点文档用一个类比切入低代码引擎之于 JavaScript 语言如同各浏览器之于 Web 标准。在浏览器/JavaScript 标准出现之前开发者被浏览器兼容性支配IE 与其他浏览器对上层 API 实现不一致一份代码要在两端运行需要做大量适配标准出现后各浏览器统一了 API开发者才得以从这部分工作中解放出来Babel 对语言特性的转换是另一层面的问题。《低代码引擎搭建协议规范》出现之前低代码领域存在类似甚至更严重的问题1. 概念不通在交流过程中搭建产品术语不一致带来了沟通成本无论在文章分享、技术分享还是交流会上都会遇到。统一协议首先统一了一组核心领域名词详见 搭建协议 1.6 名词术语物料侧名词基础组件、图表组件、业务组件含低代码业务组件、布局组件、区块、页面、模板低代码搭建系统名词搭建编辑器属性面板/画布面板/大纲面板、编辑器框架、入料模块、编排模块、渲染模块、出码模块 Schema2Code、事件绑定、数据绑定、生命周期。2. 物料孤岛由于低代码产品实现方式不同物料的消费方式也各不相同。这里分为两种物料低代码物料A 平台创建的物料无法使用到 B 平台上如果想在 B 平台实现同样的物料需要按照 B 平台的标准重新搭建一份ProCode 物料需要在低代码平台消费时进行转换包括搭建配置项的生成、物料搭建视图等可能还需要特殊的描述文件。由于这一层没有统一同一份 ProCode 物料每接入一个低代码平台可能需要的描述文件格式不同、转换代码不同、使用的工具也不同。3. 生态隔离不同低代码平台的生态体系各不相同有的物料生态不错有的搭建体验生态不错但这些利好的生态无法互通——就算知道了代码也无法复用因为底层不一致。对平台方而言每个平台都创建一份自己的生态并不是利好的。4. 低水平重复建设从个人角度看重复造轮子或许有技术成长但对低代码平台方而言更多的工作实际上集中在物料转化、物料生成、搭建体验的小优化、对部分其他平台生态的实现。这些技术深度并不高属于低水平重复建设。5. 价值不高如果每个业务都从 0 开始做自己的平台会花费大量时间构建底层基础设施而前端领域的底层基础设施大同小异重复构造造成极大的资源浪费。这样的建设会导致从 0 到 1 都需要花费大量时间在内部人力不足、投入有限时产品很容易在未发展壮大的时候就面临死亡相关的决策。设想一下如果可以开发一份所有低代码平台都可以使用的物料是否更有成就感如果可以基于已有生态快速落地低代码平台而不是花费 1-2 年搭建一个可用平台再验证市场快速验证后再进行深入打磨这其中的思考和技术含量是否更优以 2019 年某大厂的情况举例不同平台的低代码物料包括但不限于vc-deep — vc 协议 基于 Fusion Next 定制的企业组件库Iceluna 协议 Fusion NextAIMake 物料vc-fusion-basic 业务改造 — vc 协议 Fusion Next各业务 Fork 定制vision 魔改 vc 协议扩展 业务组件vc 协议 antd。可以看到各个搭建平台都需要维护一套自己的基础组件库这非常不合理对基础组件库的维护会分散开发同学完成业务目标的精力。建立统一的低代码领域标准化百利而无一害。于是在 2020 年进行了跨团队讨论建立“搭建治理 物料流通”战役此战役产出了上文中的协议规范成为低代码引擎和其生态的基础。三、协议的作用之一打破物料孤岛3.1 物料中心以集团前端物料中间建设为例在《低代码引擎物料协议规范》落地之后建立了各个中后台研发平台沟通、对话的基础物料流通的先决条件已经成熟。此时还需要一个统一的物料源用于管理物料的上传、存储、检索、分发——一个典型的中心化架构类似 npm 的管理这便是物料中心。Fusion Market 是物料中心的前身它提供了业务组件的存储、文档展示和全局透出的功能。由于 Fusion 体系在集团内的广泛使用Fusion Market 沉淀了不少业务组件但项目一直不温不火只看到业务组件数量的增加却未看到物料流通起来。其中一个原因是缺乏官方委员会的背书规范很难统一规范不统一物料就很难流通。规范成立之后物料中心才有了建设基础最终于 2019 年建立了物料中心提供物料流通的平台能力。3.2 低代码基础物料就像 AntD、Element 之于源码研发模式低代码研发模式下各个搭建平台也需要一套统一的、开箱即用的低代码基础组件库。基于低代码描述协议完成了两份低代码基础物料的建设“Fusion 低代码基础组件库”和“AntD 低代码基础组件库”。3.3 源码组件低代码化将源码组件一键转化为低代码物料使其符合低代码物料规范从而可以在低代码平台进行流通。这一能力在仓库中由 modules/material-parser 实现入口函数按accesserlocal / online区分本地源码与在线包两种来源随后经过scan扫描源码→parse解析 JSX/TS 等→generate生成物料描述三步流水线产出ComponentMeta[]。该流水线正对应搭建协议名词表中“入料模块专注于物料接入能自动扫描、解析源码组件并最终产出一份符合《低代码引擎物料协议规范》的 Schema JSON”的定义。3.4 低代码物料中心当低代码物料积累到一定量级之后所有搭建平台的业务物料越来越多。这些物料通过低代码物料中心进行统一的管理和消费。四、协议的作用之二设置器生态的基础Snippet组件默认搭建 schema由《低代码引擎搭建协议规范》定义低代码引擎会按照规范对组件进行渲染Configure由《低代码引擎物料协议规范》定义它描述了组件的 props 以及每个 prop 对应的设置器Prop 配置面板。lowcode-engine 提供了 20 个内置设置器如果组件的 props 超出了引擎内置设置器的范围就需要自行开发对应设置器。设置器最终也慢慢形成了自己的生态使得开发物料更加容易——可以使用已有生态中的设置器进行物料配置描述。从物料协议规范可以看到 Configure 的完整结构material-spec 2.2.2.4 编辑体验增强 configure包含props属性面板配置A 级、component组件能力配置含 isContainer/isModal/nestingRule 等、supports通用扩展面板支持性AA 级、advanced高级特性配置AAA 级四个维度与仓库中packages/designer的设计器能力配置相互呼应。五、协议的作用之三低代码引擎实现标准低代码引擎是以上生态的消费端它是实现了标准协议的低代码引擎。这是不可或缺的部分低代码引擎相当于一个“标准浏览器”一方面给其他低代码平台提供了 Demo其他平台可以参考低代码引擎进行实现满足官方协议便也可以消费相关的物料生态和其他生态。仓库中“协议消费端”的典型证据出码模块的版本校验modules/code-generator/src/parser/SchemaParser.ts 中SchemaParser.validate会检查schema.version是否在SUPPORT_SCHEMA_VERSION_LIST内否则抛出CompatibilityError。这直接落实了搭建协议 2.1 节“定义当前协议 schema 的版本号不同的版本号对应不同的渲染 SDK以保障不同版本搭建协议产物的正常渲染”的条款。componentsMap 到依赖的映射SchemaParser.parse 遍历schema.componentsMap将每条记录转换为外部依赖componentName、exportName、version、destructuring与搭建协议 2.2 节“组件映射关系A”中的字段一一对应最终由出码模块生成import { Select as MySelect } from alifd/next等源码语句。componentsTree 到容器的映射SchemaParser.parse 将componentsTree中每个根节点解析为容器信息IContainerInfo并根据componentName区分Page/Block/Component三类内部依赖类型落实了搭建协议“容器结构描述A”中三种容器页面容器 Page、区块容器 Block、低代码业务组件容器 Component的定义。协议类型的运行时工具packages/utils/src/schema.ts 提供了compatibleLegaoSchema将旧版协议升级成 JSExpression/JSSlot 标准结构、getNodeSchemaById等工具函数说明JSExpression、JSSlot等属性值类型在编辑器运行时被广泛依赖与搭建协议 2.3.4 节“属性值类型描述A”中的节点类型、事件函数类型、变量类型定义相吻合。六、协议结构速览搭建协议的顶层 Schema理解协议栈最有价值的是搭建协议的顶层结构。协议顶层结构如下完整字段表见 lowcode-spec 2 协议结构顶层字段类型说明versionString当前协议版本号默认 1.0.0对应不同渲染 SDKcomponentsMapArray组件映射关系componentName → npm 包导出组件componentsTreeArray描述模版/页面/区块/低代码业务组件的组件树utilsArray工具类扩展映射关系i18nObject国际化语料constantsObject应用范围内的全局常量cssString应用范围内的全局样式configObject当前应用配置信息渲染 SDK 版本、路由模式、布局、主题等metaObject当前应用元数据信息名称、git 分组、描述、创建/修改时间等dataSourceArray当前应用的公共数据源routerObject当前应用的路由配置信息pagesArray当前应用的所有页面信息一个精简的顶层示例完整版见 lowcode-spec.md{ version: 1.0.0, componentsMap: [{ componentName: Button, package: alifd/next, version: 1.0.0, destructuring: true, exportName: Select, subName: Button }], componentsTree: [{ id: page1, componentName: Page, fileName: Page1, props: {}, css: body {font-size: 12px;}, children: [{ componentName: Button, props: { valueBind: { type: JSExpression, value: this.state.user.name }, onClick: { type: JSFunction, value: function(e) { console.log(e.target.innerText) } } } }] }], i18n: { zh-CN: { i18n-jwg27yo4: 你好 }, en-US: { i18n-jwg27yo4: Hello } }, router: { baseUrl: /, historyMode: hash, routes: [{ path: home, page: page1 }] }, pages: [{ id: page1, treeId: page1 }] }协议还规定了语义版本号major.minor.patchA 级规范与子规范 Level 定义规范等级实现要求A强制规范必须实现违反此类规范的协议描述数据将无法写入物料中心不支持流通AA推荐规范推荐实现有助于业务未来的扩展性和跨团队合作研发效率的提升AAA参考规范根据业务场景实际诉求实现是集团层面鼓励的技术实现引导其设计说明强调五点语义化语义清晰、可读性强、渐进性描述从组件到区块、页面、应用逐级组合、生成标准源码每个属性与源码转换关系明确可生成与手写无差异的高质量标准代码、可流通性产物不涉私域数据可在不同搭建产品间流通、面向多端不局限于 React还包括小程序等多端。七、小结协议栈如何串联“入料—搭建—渲染—出码”回到《协议栈简介》的核心结论三份协议是低代码领域标准化的基石。结合本仓库可以看到完整闭环——物料协议docs/docs/specs/material-spec.md约束源码组件的目录、API 与组件描述configure/snippets由 modules/material-parser 的 scan → parse → generate 流水线自动生产搭建协议docs/docs/specs/lowcode-spec.md约束搭建产物的 Schema 结构componentsMap / componentsTree / 容器 / 数据源 / 事件 / 国际化是编辑、渲染、出码三方共享的“中间语言”渲染模块packages/react-renderer、packages/renderer-core与出码模块modules/code-generator都只消费协议数据各自独立升级资产包协议docs/docs/specs/assets-spec.md则支撑物料中心的统一管理、检索与流通使“一份物料、多平台消费”成为可能。这套以协议为中心、以引擎为标准实现的设计正是 lowcode-engine 面向扩展scale-out设计的核心任何满足官方协议的平台都可以直接消费协议生态中的物料与设置器避免概念不通、物料孤岛、生态隔离与低水平重复建设。【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考