文：清凌渡 题拍拍前端开发专家

中后台应用主要用于信息的查询、展示和修改，并把数据变更持久化到数据库中，可以看作传统数据管理平台的延伸。产品形态可以被收敛为 UI 模式一致的标准化组件库，比如 Ant Design、AntV 等通用 UI 库是中后台产品前端开发的事实标准。

在低代码平台中，所见即所得的组装中后台应用，代替纯手工的代码编写，可以大幅提升开发的效率和质量。

基于业界优秀的前端基础组件，进行低代码平台的开发，成本和难度基本可控，其关键工作是低代码平台底层规范的设计，即实现低代码平台的领域专用语言（下面简称“DSL”）。

一、应用解构

如下图所示，一个中后台应用主要有表单页、列表页、详情页 3 种页面形态，粗粒度总结如下：

1. 表单页面主要包含表单组件和选择组件两种；
2. 列表组件主要包含过滤组件、表格组件、分页组件 3 种，其中表格组件可以包含单元格组件。
3. 详情页面主要包含列表组件和图表组件。

在典型的中后台开发过程中，前端工程师的工作可以分为应用的静态组织部分和状态的动态转移部分两大类。

如上图所示，中后台应用的组织结构，是一棵典型的树形结构：

1. 应用组织结构由应用、页面、组件 3 层结构组合而成；
2. 应用通过 Route Children 组织页面，并且 route Children 支持递归组织多层次路由，页面支持递归组织多层 Layout 布局；
3. 页面通过 Template 组织组件；
4. 组件管理内部状态的转移和行为事件的响应，比如：
1. API 请求（GET），状态 JSON 数据从服务端发送到客户端，建议通过配置在组件内部编码完成；
2. API 上报（POST），状态从客户端表单数据上报到服务端，客户端状态生成的主要载体是表单组件，建议通过配置在组件内部编码完成。

状态转移进一步串联应用的整体功能，主要满足页面的跳转：

1. 参数传递（Params，如上图中的 Route Query），从列表页面跳转到详情页面。由 Route Params 来实现，即用 RESTful 风格，传递 ID 等关键参数，用 RESTful 风格的优势如下。

低代码平台的领域专用语言，即要支持完整的应用组织和状态转移，来完成应用的构建。整个应用的静态结构组织通过搭建来进行配置是非常容易的，如何简洁的完成动态的状态转移是低代码平台易用性的关键，建议通过约定来完成：

1. 低代码编辑器部分仅仅保留配置，不提供编码支持；
2. 复杂逻辑完全封装到组件内部，低代码编辑器仅仅勾选配置配置或填写静态字符串；
3. 组件是低代码平台的资产积累，也是前端工程师的专业领域。

二、设计思路

钉钉的宜搭、腾讯的云开发低码平台等业界方案，都是私有协议。虽然私有协议的自主性看似更高，但如果初期设计不周全，后续的升级会被兼容性严重拖垮。

另一种思路是基于“现成/开源”的领域专用语言之上，定义一份规范，即封装开源协议。

从自主性、完备性、扩展性、易用性、ROI5 个方面，两种思路对比如下图：

本文基于 Vue SFC（单文件组件）、Vue Compiler-Core、Vue-Router 的 Vue 通用全家桶，从中选择需要的部分类定义进行规范化，来完成 DSL 的设计。这个思路最大的优势是：和大家熟悉的 Vue 事实规范保持了一致，DSL 是一个新库，也是一个 6 年的成熟项目。同时满足了基本的向前兼容性要求——当未来的对低代码平台产生新的需要，只需要选择另外一部分类定义进行规范化。

三、DSL 和 SDK 设计

一个完备的 DSL 定义（语义和语法）需要满足应用组织和状态转移的诉求。DSL 核心组件和总体方案如下：

1. 应用通过路由把页面组织在一起，构成完整的应用，使用 Vue-Router 进行规范和描述。
2. 页面由组件组合（兄弟、嵌套两种形式）而成，页面中组件的声明和关系使用 Vue Compiler-Core 进行规范和描述；
3. 组件遵循 SFC 规范。

3.1 应用规范设计

应用规范如下图所示，包含元信息和路由结构 2 部分组成。

1. 路由和页面通过 PageID 外联；
2. 页面通过路由传递状态（数据）——整个应用中，可配置状态的传递仅通过路由完成；
3. 路由的层次虽然跟菜单的层次是两个相互独立的信息，为了简化，可以把路由信息作为菜单信息来使用。

3.2 页面规范设计

页面规范如下图所示，主要包含元信息和页面结构两部分，分为布局页面（比如主导航部分）和落地页面（详情部分、列表部分）两种，布局页面页面可以嵌套，落地页面被包含在布局页面中。

3.3 组件规范

组件规范如下图所示，需要遵循 Vue 的 SFC 规范，元信息主要包含组件标识、属性描述、规范版本 3 部分。

3.4 组件节点依赖关系

基于 Vue Compiler-Core，封装了如下 7 类节点，其依赖关系如下：

每个 **NodeDSL 均对应一个 **Node 类，前者是 Plain Object、后者是编辑器程序中操作 DSL 的类，这 4 个基本类中均支持下面 4 个方法：

1. 构造方法，参数为部分 DSL 格式的 Plain Object；
2. 更新方法，参数为部分 DSL 格式的 Plain Object
3. 序列化方法，返回相应 DSL 格式的 Plain object，用于数据库的存储；
4. 反序列化方法，参数是完整 DSL 格式的 Plain Object，将当前对象实例进行更新，用于二次编辑。

3.5 示例代码

3.5.1 应用组装示例

通过上面的 SDK，操作应用中 DSL 的代码如下所示：

import Application, { ApplicationDSL } from './Application';import Route, { RouteDSL } from './Route';import Page, { PageDSL } from './Page';import ElementNode, { ElementNodeDSL } from './ElementNode';const app = new Application({});const page = new Page({});const route = new Route({meta: { pageId: page.meta.uuid, page: page }});app.routeInsertInto(route, undefined);const component = new ElementNode({ tag: 'TheBothLayout', propsScheme: { properties: { menus: { title: '菜单', type: 'array', default: '', } }, }, });page.componentInsertInto(component, undefined);

3.5.2 序列化后的结构示例

{ "meta": { "name": "", "uuid": "1fafcf93-99adb0b18564", "specVersion": "0.1.0" }, "body": [ { "children": [], "meta": { "uuid": "a0eced40-ee12609d586e", "pageId": "0729c617-9f75e32f8fc4", "specVersion": "0.1.0" } } ] }

四、进一步思考

低代码本质上是最佳实践的模板化使用，如下图所示，既是闭环内最佳实践产品化的过程，也是外层产品对内层产品规模化复用和反馈的闭环：

1. 标准流程是经验的资产化——把前端工程师个体经验总结、沉淀、统一为“标准件”、“中间件”产品，比如优秀的前端库 Ant Design；
2. 工具系统是标准的资本化——比如在低代码平台中可视化的组装 Ant Design，大幅降低 App 生产的边际成本；
3. 数据智能是工具的自动化——比如 imgcook（https://www.imgcook.com/）由设计稿智能生成代码。

从工程执行的角度，低代码的目标是提效，不是把前端工程师的工作量转移给后端工程师、产品经理、测试老师等，而是和原有工作整合后的提效和提质——其本质是重复工作的标准化和自动化，把前端工程师从生产过程中下沉于基建和物料库建设来支撑提效；或把高复杂度工作降低出错的概率。

从用户的视角，低代码有两层含义：

1. 更简单的配置，而不是深奥代码的可视化编写：
1. 复杂的代码封装为组件，下沉到物料库中——这应该是专业前端工程师把自身手艺总结为界面简单的标准组件的生产过程，产出的组件在低代码编辑器中配置化使用；而不是在低代码编辑器中进行深奥的手艺总结；
2. 更少量的配置，而不是复杂代码的可视化重复：
1. 重复的代码总结为标准，操作过程自动化——这应该是标准组件进一步模板化使用的过程；而不是重复的工作反复点击鼠标。

作者:清凌渡 题拍拍前端开发专家

来源:微信公众号:题拍拍技术团队

出处:https://mp.weixin.qq.com/s/jrTvj_slJWhj-TC2E_xKHQ