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

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

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

  • 低代码平台核心的底层逻辑是什么?
  • 为何常见低代码平台都包含“控件区”、“布局区”和“属性编辑区”?
  • 低代码平台的控件、组件、画布的本质是什么?
  • 如果让低代码平台支持跨平台?
  • 如何让低代码平台支持自定义数据源?
那让我们开始吧?。
一、你所看见过的低代码平台 近几年国内纷纷出现各种低代码产品,在降本增效提质方面发挥重要作用。低代码平台的业务场景涉及越来越广泛:自定义表单、页面制作、活动详情页、工作流场景、数据报表、大屏数据报表、数据表格、白板笔记等等。对应成熟的低代码产品也非常多:阿里宜搭、腾讯云搭、百度爱速搭、轻流、Jeecg Boot、码良等等。
下图腾讯开源的 tmagic 平台,是我们最常见的低代码平台布局方式:
试着换个角度理解低代码平台设计的本质
文章图片

(本图来自: tmagic )
其中包括三个核心模块:
  • 控件区:展示平台内支持的控件,用户通过拖拽控件到布局区,即可展示控件对应的 UI 组件样式;
  • 布局区:用来承载控件对应的 UI 组件,用户可以对每个 UI 组件进行布局,并且直观查看页面效果;
  • 属性编辑区:用来展示该控件支持的配置内容,可以更加灵活的对每个控件对应的 UI 组件进行自定义设置。
所以,为何各个产品纷纷采用这类布局?
二、换个角度思考低代码平台设计 我们在解决问题时,经常会使用两种方法:
  • 自顶向下法:从目标出发,拆解和细化问题,找到解决方法;
  • 自底向上法:汇总各种零散信息,得到正确方法和结论。
我们试着用自顶向下法思考一下低代码平台的设计:
通常在团队确定是否需要开发低代码平台前,都会通过头脑风暴、灵感讨论、业务需要情况分析,然后确定开发低代码平台的原始需求。
试着换个角度理解低代码平台设计的本质
文章图片

假设这么一个场景:
掘金社区的主页布局比较单一,当需要增加或调整部分模块时,需要改动项目代码、打包、提测、发布,这时候如果能有一个主页设计平台,让运营人员自由调整页面布局,还可以针对不同节日、活动调整出不同主页布局。
试着换个角度理解低代码平台设计的本质
文章图片

基于这样的场景,我们使用自顶向下法,从目标出发,拆解和细化问题,找出解决方法。
1. 确定目标
我们的目标需求是能够灵活的布局社区主页:
试着换个角度理解低代码平台设计的本质
文章图片

2. 拆解和细化问题
如果要实现灵活布局的掘金主页,就需要将主页中的模块抽成每个独立控件:
试着换个角度理解低代码平台设计的本质
文章图片

如果每个控件需要能够灵活配置,我们还需要能够配置控件的任意部分:
试着换个角度理解低代码平台设计的本质
文章图片

3. 找到解决方法
按照前两个步骤的分析,我们可以确定大致解决方法:
  1. 需要实现一个支持自由拖拽布局的设计平台;
  2. 该平台支持拖拽不同控件到页面中;
  3. 每个控件支持不同的自定义配置;
  4. 设计器支持导出页面结构,渲染器支持渲染页面内容。
于是我们就有了下面的方案:
试着换个角度理解低代码平台设计的本质
文章图片

这样是为什么常见低代码平台都会有“控件区”、“布局区”和“属性编辑区”。
通常交互逻辑如下:
  1. 从「控件区」拖拽一个控件进入「布局区」,将控件渲染成对应组件;
  2. 选中组件,在「属性配置区」显示该组件所有支持配置的属性;
  3. 修改「属性配置区」的属性,更新「布局区」中该组件的样式。
试着换个角度理解低代码平台设计的本质
文章图片

这是最简单的一个流程。
三、思考更加通用的低代码模型 低代码平台创建的页面,本质上不一定是单个页面,也可以是由多个页面组成的一个 Web 应用,因此,我们可以把上面示例,抽象成更加通用的低代码平台模型:
试着换个角度理解低代码平台设计的本质
文章图片

该模型定义了低代码平台创建的页面结构,最终的渲染是由对应渲染器渲染页面。
这就有点 VNode 树的味道啦。
试着换个角度理解低代码平台设计的本质
文章图片

(图片来源:https://v3.cn.vuejs.org/)
对于 Vue 而言,核心要解决的就是“如何创建 VNode”和“如何渲染 VNode”。
接下来我们通过 TypeScript 接口形式定义下面的结构:
试着换个角度理解低代码平台设计的本质
文章图片

可以发现,单页应用和多页应用的关系在于,通过为单页应用增加 path配置,将多个单页应用组合成多页应用。
到这里我们就有一个更加通用的低代码模型,并且使用 TypeScript 接口定义了每一层的结构。
可以看出:低代码平台的核心在于模型设计,定义每个部分的模型。
四、控件区的控件没这么简单 1. 控件是什么?
控件本质是一个标准的 JSONSchema 对象,用来描述最终渲染出来的组件。在低代码平台中,将控件拖拽到布局区才会显示对应的组件样式。
以「用户信息控件」为例:
const UserInfo = { name: '用户信息控件', type: 'UserInfoComponent', // 指定渲染的组件名称 config: [ { label: '头像', type: 'input', value: 'https://a.com', }, { label: '昵称', type: 'input', value: 'pingan8787' } ] }

通常我们会在控件对象中定义一个 type(也可能是其他名称),用来指定控件所渲染的组件名称。比如 Vue 中,就可以通过该 type 值,使用动态组件 形式动态渲染组件。
试着换个角度理解低代码平台设计的本质
文章图片

控件就好比是组件的说明书,只是对组件进行描述,描述了它是什么样子,有哪些行为、配置等信息。
2. 控件还有什么优点?
控件定义成标准的 JSON 对象,还有其他优点没比如:可以实现控件跨平台适配,在不同平台/组件库渲染不同的组件。目标平台只需按照模型渲染不同组件即可。
试着换个角度理解低代码平台设计的本质
文章图片

3. 控件如何实现动态加载远程组件?
常见的方案是为每个控件指定远程组件的地址(如设置 path 属性),当控件开始被拖拽时,发送请求获取远程组件:
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. 开始拖拽「控件区」控件,并发起请求,从服务端获取远程组件;
  2. 当获取到远程组件后,注册到项目中;
  3. 松开控件,渲染组件内容到「画布区」。
当然,考虑到编辑器的性能优化,避免每次拖拽都发送请求获取组件文件,我们可以这样优化:
  • 使用请求缓存,如果是重复请求,则从缓存读取上次请求结果;
  • 对常用基础组件预先发送请求并保存本地;
  • 本地缓存已请求的组件,下次请求相同组件,则读取缓存结果;
  • 等等
五、画布区的画布也没这么简单 1. 画布是什么?
画布的本质也是一个标准 JSON 对象,它是我们最终要渲染页面所用的数据源,通常包含整个页面的结构和配置信息。当拖拽控件进入画布和更新组件配置时,会更新画布。
我们根据掘金主页,简单构造一个模型(不考虑多页面情况):
const Juejin = { title: '掘金主页', favicon: './favicon.icon', components: [ { name: '用户信息控件', type: 'UserInfoComponent', config: [ { label: '头像', type: 'input', value: 'https://a.com', }, { label: '昵称', type: 'input', value: 'pingan8787' } ] } ] }

在上面模型中,定义了画布中的每个组件,存放在 components数组下,每个组件都包含各自的 nametypeconfig等信息,在渲染器渲染时,就可以:
  • 根据 type渲染配置区的组件;
  • 根据 label 渲染配置区表单的 label 文本;
  • 根据 value渲染配置区表单的值。
2. 画布还有丰富的配置
对于画布模型,最重要的应该是组件列表,即前面的 components数组,对于每一个组件,最主要的信息包括:
  • 事件模型信息:包含该组件绑定的一些事件(如事件名称等);
  • 动画模型信息:包含该组件绑定的一些动画效果(如旋转、放大等);
  • UI 样式模型信息:包含该组件绑定的一些 UI 样式(如背景色、字号等);
  • 数据/数据源模型信息:包含该组件绑定的一些数据源相关的配置(如数据源接口地址等)。
以「事件模型信息」为例,当页面中配置了一个按钮,这个按钮往往可以做如下事情:
  • 打开链接;
  • 打开弹框;
  • 打开 APP;
  • 刷新页面;
  • 发送请求;
  • 等等。
此时,该按钮可触发的行为非常多,如果把每个事件处理逻辑都写在组件中,会使得组件臃肿无比,且耦合在组件中,可维护性差。
为了降低组件和事件处理逻辑之间的耦合度,我们可以在组件和事件处理逻辑中间增加一层,即事件总线:
试着换个角度理解低代码平台设计的本质
文章图片

实现通用组件派发事件到事件总线,不同的业务场景监听事件,执行具体的事件处理逻辑。
通过事件总线,将派发事件和监听事件的双方互相解耦,完成解耦后,还能够实现跨平台的功能,对于派发相同的事件,只需要在不同平台监听该事件,实现不同的处理逻辑即可。
六、数据源设计 所谓「数据源」即低代码平台中数据来源,通常按照业务需求可以将数据源分为两类:
  • 静态数据源:数据绑定在页面配置中,在最终效果页时,直接使用页面配置中的数据,无需通过接口获取数据;
  • 动态数据源:一般是保存数据源的接口在配置中,不绑定数据,在最终效果页时,客户端需要再发送请求获取数据。
1. 静态数据源的过程
在低代码设计平台中,平台先请求数据,用户选择其中指定数据,保存在页面配置中。
比如当我们已有 banner 列表接口,需要选择其中一张,添加到布局区中:
试着换个角度理解低代码平台设计的本质
文章图片

步骤如下:
  1. 用户在「控件区」选择「轮播控件」,拖入「布局区」;
  2. 点击「布局区」中「轮播控件」的组件,打开「属性配置区」;
  3. 选择「属性配置区」中「选择 banner」,平台发送请求,从服务端获取 banner 列表;
  4. 打开「选择 banner 弹框」,展示 banner 列表,用户选择所需 banner 图片;
  5. 点击「确定」,关闭「选择 banner 」弹框,并在「布局区」的「轮播控件」组件插入该笔数据,完成选择。
用户在「选择 banner」弹框中,选中指定的数据,保存到页面配置中,当访问最终生成效果页,会直接显示出已选择的 banner 图片。
2. 动态数据源的过程
动态数据源相比静态数据源,会更加灵活,用户指定数据源接口后,当接口数据变化,最终效果页可以动态改变展示的内容。
比如当我们已有 banner 列表接口,可以在管理后台添加不同的 banner,最终效果页能够展示新的 banner,而用户只需在设计时,指定 banner 列表接口即可:
试着换个角度理解低代码平台设计的本质
文章图片

步骤如下:
  1. 用户在「控件区」选择「轮播控件」,拖入「布局区」;
  2. 点击「布局区」中「轮播控件」的组件,打开「属性配置区」;
  3. 选择「属性配置区」中「配置 banner」,配置“接口地址”和“转换规则”;
  4. 选择完成,点击「确定」,关闭「选择 banner 」弹框,将配置的“接口地址”和“转换规则”数据保存在「布局区」页面配置中,配置完成。
  5. 当用户访问最终效果页时,页面会先调用配置的“接口地址”获取远程的 banner 列表;
  6. 将接口返回的数据通过“转换规则”,将接口返回的数据转换成组件所有的数据格式。
这样就实现了最终效果页能够每次都展示最新的数据,实现完全动态。
3. 增加数据源适配器
当需要对两个耦合度较高的逻辑进行解耦,可以通过增加适配器方法进行解耦,因此在数据源这边也可以增加适配器对「UI 组件」和「接口数据」进行解耦。
理想状态应该是:
  • UI 组件只对外暴露组件支持的配置和方法,而无需关注是什么业务使用该组件;
  • 接口数据也无需关注数据被什么组件使用。
于是,我们分别为「静态数据源」和「动态数据源」增加了数据适配器,流程如下:
  • 静态数据源
试着换个角度理解低代码平台设计的本质
文章图片

在第 4 步时,接口返回的数据会经过「数据适配器 1」,将接口数据转换为「选择 banner」弹框组件统一的参数。同理,第 6 步将弹框组件返回的数据结构,通过「数据适配器2」转换为「banner 组件」所需参数的数据结构。
  • 动态数据源
试着换个角度理解低代码平台设计的本质
文章图片

在第 6 步时,接口返回的数据会经过「数据适配器 」,将接口数据转换为「banner 组件」统一的参数数据结构。
其实总结一下,就是通过各种数据适配器,将各种来源的数据结构转换为组件的参数模型即可。好处也很明显:
  • 更换数据源时,只需要按照组件参数模型对接接口,实现各种数据适配器,无需改动原有逻辑;
  • 更换 UI 组件库时,也只需要按照组件参数模型对接 UI 组件,实现各种数据适配器,无需改动原有逻辑。
4. 总结数据源设计
按照前面的方案,我们对数据源就有了主要方向,其主要的核心在于:通过定义组件接口模型和适配器模型,我们可以很容易的开发任意组件和适配器,按照定义的模型,其他开发者也能很方便的开发。
七、总结 低代码平台作用在于降本增效提质,核心在于模型设计,降低各个功能点的耦合度,让平台支持跨平台。
本文通过自顶向下法,介绍低代码平台的设计思路,从目标出发,拆解和细化问题,找到解决方法。后面针对低代码平台的几个核心模块逐一分析自己的理解,着重介绍了核心模块的模型设计和配置。
本文是自己经过几个低代码平台实战后的理解和总结,希望对各位有所帮助,低代码平台的未来无限可能。
【试着换个角度理解低代码平台设计的本质】这是我第一次写低代码相关的文章,如有错误,欢迎指正~~

    推荐阅读