试着换个角度理解低代码平台设计的本质

本文会主要分享自己对低代码平台的理解，从多个角度和问题去看低代码平台的设计。我觉得低代码平台的核心在于模型设计，包括控件模型、组件模型、画布模型等等。希望看完本文，你能知道：

低代码平台核心的底层逻辑是什么？
为何常见低代码平台都包含“控件区”、“布局区”和“属性编辑区”？
低代码平台的控件、组件、画布的本质是什么？
如果让低代码平台支持跨平台？
如何让低代码平台支持自定义数据源？

那让我们开始吧。

一、你所看见过的低代码平台

近几年国内纷纷出现各种低代码产品，在降本增效提质方面发挥重要作用。低代码平台的业务场景涉及越来越广泛：自定义表单、页面制作、活动详情页、工作流场景、数据报表、大屏数据报表、数据表格、白板笔记等等。对应成熟的低代码产品也非常多：阿里宜搭、腾讯云搭、百度爱速搭、轻流、Jeecg Boot、码良等等。

下图腾讯开源的 tmagic 平台，是我们最常见的低代码平台布局方式：

（本图来自： tmagic ）

其中包括三个核心模块：

控件区：展示平台内支持的控件，用户通过拖拽控件到布局区，即可展示控件对应的 UI 组件样式；
布局区：用来承载控件对应的 UI 组件，用户可以对每个 UI 组件进行布局，并且直观查看页面效果；
属性编辑区：用来展示该控件支持的配置内容，可以更加灵活的对每个控件对应的 UI 组件进行自定义设置。

所以，为何各个产品纷纷采用这类布局？

二、换个角度思考低代码平台设计

我们在解决问题时，经常会使用两种方法：

自顶向下法：从目标出发，拆解和细化问题，找到解决方法；
自底向上法：汇总各种零散信息，得到正确方法和结论。

我们试着用自顶向下法思考一下低代码平台的设计：

通常在团队确定是否需要开发低代码平台前，都会通过头脑风暴、灵感讨论、业务需要情况分析，然后确定开发低代码平台的原始需求。

假设这么一个场景：

掘金社区的主页布局比较单一，当需要增加或调整部分模块时，需要改动项目代码、打包、提测、发布，这时候如果能有一个主页设计平台，让运营人员自由调整页面布局，还可以针对不同节日、活动调整出不同主页布局。

基于这样的场景，我们使用自顶向下法，从目标出发，拆解和细化问题，找出解决方法。

1. 确定目标

我们的目标需求是能够灵活的布局社区主页：

2. 拆解和细化问题

如果要实现灵活布局的掘金主页，就需要将主页中的模块抽成每个独立控件：

如果每个控件需要能够灵活配置，我们还需要能够配置控件的任意部分：

3. 找到解决方法

按照前两个步骤的分析，我们可以确定大致解决方法：

需要实现一个支持自由拖拽布局的设计平台；
该平台支持拖拽不同控件到页面中；
每个控件支持不同的自定义配置；
设计器支持导出页面结构，渲染器支持渲染页面内容。

于是我们就有了下面的方案：

这样是为什么常见低代码平台都会有“控件区”、“布局区”和“属性编辑区”。

通常交互逻辑如下：

从「控件区」拖拽一个控件进入「布局区」，将控件渲染成对应组件；
选中组件，在「属性配置区」显示该组件所有支持配置的属性；
修改「属性配置区」的属性，更新「布局区」中该组件的样式。

这是最简单的一个流程。

三、思考更加通用的低代码模型

低代码平台创建的页面，本质上不一定是单个页面，也可以是由多个页面组成的一个 Web 应用，因此，我们可以把上面示例，抽象成更加通用的低代码平台模型：

该模型定义了低代码平台创建的页面结构，最终的渲染是由对应渲染器渲染页面。

这就有点 VNode 树的味道啦。

（图片来源：https://v3.cn.vuejs.org/）

对于 Vue 而言，核心要解决的就是“如何创建 VNode”和“如何渲染 VNode”。

接下来我们通过 TypeScript 接口形式定义下面的结构：

可以发现，单页应用和多页应用的关系在于，通过为单页应用增加 path配置，将多个单页应用组合成多页应用。

到这里我们就有一个更加通用的低代码模型，并且使用 TypeScript 接口定义了每一层的结构。

可以看出：低代码平台的核心在于模型设计，定义每个部分的模型。

四、控件区的控件没这么简单

1. 控件是什么？

控件本质是一个标准的 JSONSchema 对象，用来描述最终渲染出来的组件。在低代码平台中，将控件拖拽到布局区才会显示对应的组件样式。

以「用户信息控件」为例：

代码语言：typescript复制

const UserInfo = {
    name: '用户信息控件',
    type: 'UserInfoComponent', // 指定渲染的组件名称
    config: [
        {
            label: '头像',
            type: 'input',
            value: 'https://a.com',
        },
        {
            label: '昵称',
            type: 'input',
            value: 'pingan8787'
        }
    ]
}

通常我们会在控件对象中定义一个 type（也可能是其他名称），用来指定控件所渲染的组件名称。比如 Vue 中，就可以通过该 type 值，使用动态组件 <component :is={type} />形式动态渲染组件。

控件就好比是组件的说明书，只是对组件进行描述，描述了它是什么样子，有哪些行为、配置等信息。

2. 控件还有什么优点？

控件定义成标准的 JSON 对象，还有其他优点没比如：可以实现控件跨平台适配，在不同平台/组件库渲染不同的组件。目标平台只需按照模型渲染不同组件即可。

3. 控件如何实现动态加载远程组件？

常见的方案是为每个控件指定远程组件的地址（如设置 path 属性），当控件开始被拖拽时，发送请求获取远程组件：

代码语言：typescript复制

const UserInfo = {
    name: '用户信息控件',
    type: 'UserInfoComponent', // 指定渲染的组件名称
    path: 'https://a.com/UserInfoComponent.js', // 远程组件的地址
    config: [
        {
            label: '头像',
            type: 'input',
            value: 'https://a.com',
        },
        {
            label: '昵称',
            type: 'input',
            value: 'pingan8787'
        }
    ]
}

以 Vue 为例，当获取到远程 Vue 组件后，可以通过 Vue 提供的动态组件进行注册和使用。

完整过程如下：

开始拖拽「控件区」控件，并发起请求，从服务端获取远程组件；
当获取到远程组件后，注册到项目中；
松开控件，渲染组件内容到「画布区」。

当然，考虑到编辑器的性能优化，避免每次拖拽都发送请求获取组件文件，我们可以这样优化：

使用请求缓存，如果是重复请求，则从缓存读取上次请求结果；
对常用基础组件预先发送请求并保存本地；
本地缓存已请求的组件，下次请求相同组件，则读取缓存结果；
等等

五、画布区的画布也没这么简单

1. 画布是什么？

画布的本质也是一个标准 JSON 对象，它是我们最终要渲染页面所用的数据源，通常包含整个页面的结构和配置信息。当拖拽控件进入画布和更新组件配置时，会更新画布。

我们根据掘金主页，简单构造一个模型（不考虑多页面情况）：

代码语言：typescript复制

const Juejin = {
    title: '掘金主页',
    favicon: './favicon.icon',
    components: [
        {
            name: '用户信息控件',
            type: 'UserInfoComponent',
            config: [
                {
                    label: '头像',
                    type: 'input',
                    value: 'https://a.com',
                },
                {
                    label: '昵称',
                    type: 'input',
                    value: 'pingan8787'
                }
            ]
        }
    ]
}

在上面模型中，定义了画布中的每个组件，存放在 components数组下，每个组件都包含各自的 name、type、config等信息，在渲染器渲染时，就可以：