为了账号安全,请及时绑定邮箱和手机立即绑定
首页 手记 试着换个角度理解低代码平台设计的本质

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

2022.07.20 07:56 1825浏览

图片描述

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

  • 低代码平台核心的底层逻辑是什么?

  • 为何常见低代码平台都包含“控件区”、“布局区”和“属性编辑区”?

  • 低代码平台的控件、组件、画布的本质是什么?

  • 如果让低代码平台支持跨平台?

  • 如何让低代码平台支持自定义数据源?

那让我们开始吧​。

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

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

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

tmagic

(本图来自: tmagic

其中包括三个核心模块:

  • 控件区:展示平台内支持的控件,用户通过拖拽控件到布局区,即可展示控件对应的 UI 组件样式;

  • 布局区:用来承载控件对应的 UI 组件,用户可以对每个 UI 组件进行布局,并且直观查看页面效果;

  • 属性编辑区:用来展示该控件支持的配置内容,可以更加灵活的对每个控件对应的 UI 组件进行自定义设置。

所以,为何各个产品纷纷采用这类布局?

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

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

  • 自顶向下法:从目标出发,拆解和细化问题,找到解决方法;

  • 自底向上法:汇总各种零散信息,得到正确方法和结论。

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

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

7

假设这么一个场景:

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

juejin

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

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 值,使用动态组件 <component :is={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. 总结数据源设计

按照前面的方案,我们对数据源就有了主要方向,其主要的核心在于:通过定义组件接口模型和适配器模型,我们可以很容易的开发任意组件和适配器,按照定义的模型,其他开发者也能很方便的开发。

七、总结

低代码平台作用在于降本增效提质,核心在于模型设计,降低各个功能点的耦合度,让平台支持跨平台

本文通过自顶向下法,介绍低代码平台的设计思路,从目标出发,拆解和细化问题,找到解决方法。后面针对低代码平台的几个核心模块逐一分析自己的理解,着重介绍了核心模块的模型设计和配置。

本文是自己经过几个低代码平台实战后的理解和总结,希望对各位有所帮助,低代码平台的未来无限可能。

这是我第一次写低代码相关的文章,如有错误,欢迎指正~~

点击查看更多内容

本文首次发布于慕课网 ,转载请注明出处,谢谢合作

0人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
Web前端工程师
手记
粉丝
46
获赞与收藏
231

关注TA,一起探索更多经验知识

同主题相似文章浏览排行榜

风间影月说签约讲师

50篇手记,涉及Java、MySQL、Redis、Spring等方向

进入讨论

Tony Bai 说签约讲师

142篇手记,涉及Go、C、Java、Python等方向

进入讨论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消