前言
低代码表单设计器后端技术分析。 明天的后端早读课由百度@开方投稿分享。
@开源,从事后端开发10多年,做过美工、剪页面,写过jQuery、Backbone、Angular、React、Vue等,经历了整个后端开发时期从刀耕火种的农业到工业革命。 参与并负责BI数据分析平台、BPM工作流平台等多个系统的后端开发。 目前担任低代码应用平台后端负责人。
正文从这里开始~~
低代码平台并不是什么新鲜事,它们已经存在很长时间了。 例如国外较早的建站程序Discuz,提供企业网站一键快速部署在云平台上的功能。 这是一个低代码平台吗? 我认为是这些。 如果把低代码的概念广义化的话,后端UI组件库算不算低代码呢? 即使所有可以通过 UI 操作大规模生产交付成果的平台也应该被视为低代码。 由于它们都提供了一些开箱即用的功能,增加了日常开发的复杂度和成本,提高了交付效率。
为什么低代码的概念这三年突然流行起来? 我认为激励措施与时代背景和产业转型是分不开的。
社会正在加速迈入数字化时代……在工业数字化背景下,传统企业在数字化转型过程中需要解决企业运营效率提升等问题,因此一批厂商提供类似的解决方案服务已经出现在企业市场。 此类厂商提供的服务在创投圈和资本市场被包装成低代码概念的独角兽,因此低代码概念开始流行。
一般来说,低代码平台具有以下功能:
这个世界上没有一种产品可以解决所有问题。 它们也是低代码平台。 不同厂商、团队推出的产品定位不同、场景不同,产品功能设计自然也会存在差异。
明天主要是根据我在低代码领域的开发经验,分享一些BPM表单设计器的开发实践。
BPM工作流程平台简介
开发过BPM的朋友都知道,它是一个定位于审批流程的平台级产品,工作量最大、复杂度最高的模块主要是流程设计器和表单设计器。
由于表单设计器是大多数低代码平台中的通用组件,因此它是低代码产品中相对具有代表性的表单。 尤其是在BPM这样定位于审批场景的平台中,表单设计器的作用越来越凸显,所以明天的分享将主要通过BPM表单设计器来进行。
首先,虽然本文介绍的BPM表单设计器是基于Vue.js开发的,但昨天想分享的更多的是低代码平台的设计思想以及一些核心功能点的开发技术解决方案分析。 这方面本身与编程语言和框架无关。 无论你是从事Vue.js或React.js开发的后端朋友,还是对低代码开发感兴趣的前端朋友,希望本次分享能够有所收获和启发。
BPM表单设计器案例后端技术分析
我们看一下BPM中表单设计器的界面图:
如果你接到这个任务,想要开发这个表单设计器,当你听到这个UI界面时,你的开发思路是什么?
好吧,在进入技术分析之前,我们先关注一个概念:后端状态管理。
后端状态管理
后端状态管理本质上是后端本地存储技术,也称为Store。 这个概念对于后端朋友来说并不陌生。 我开始谈论这个概念是因为设计一个好的 Store 对于复杂项目的编程至关重要。 这一点怎么强调都不为过。如何设置
计算机程序的数据结构,如何管理和使用这些数据? 这个问题应该在开发早期就被识别出来。
Store就像运行在客户端的Redis,数据存储在显存中。 Store的设计过程本质上和服务器端设计数据库表结构的过程是一样的。 数据结构为JSON格式,表单组件的配置数据和表单布局的数据最终持久化存储在MongoDB中。
不同的后端技术栈都有各自的实现,比如Vue的Vuex和Piniacss表格合并单元格,React的Redux和MobX,以及近年来流行的功能组件状态管理Hooks。 统一管理以及如何对数据进行操作(CRUD)。 无论相关技术如何发展,改变的是编程范式,不变的是状态管理的本质。
store的作用:第一次从服务器获取数据,再次访问数据时直接从store获取数据。
Store的好处:一是解决了后端模块之间的数据共享,二是通过减少HTTP请求来提高页面渲染性能。
通过这些设计,在表单设计者交互密集、模块联动频繁的场景下,可以肉眼可见地提升产品体验。
在数据驱动的接口后端技术背景下,首先要解决的就是数据的设计和管理。 项目体量越大,后端项目的复杂度越高,后端状态管理的使用就会越深入。
想象一下,如果低代码平台的后端用jQuery开发,开发难度有多大? 人们可以想象!
表单组件
常规组件有:文本组件、文本框组件、单选框组件、多选框组件、下拉框组件。
复杂组件包括:日期选择组件、上传文件组件、子表单组件等。
不同平台的表单组件生态存在较大差异。
表单组件的数据结构
仅列出一些:
文本组件:
文本框组件:
下拉框组件:
说真的,您可能已经注意到一些表单组件包含一些常见的数组。
表单组件的公共数组:
除了这个公共数组之外,其他数组都是特定于不同表单组件的扩展数组。 例如,options 是单选框、多选框、下拉框的选项列表数组,fileList 是上传文件的文件列表数组。
表单组件依赖的UI组件库
BPM表单设计器的表单组件是基于第三方UI组件库的二次封装实现的。 PC端和联通端选择了不同的UI组件库。 表单组件和业务逻辑是分开设计的。 如果将来需要修改、升级UI交互,或者减少新的组件,可以轻松替换或扩展代码。 模块整体设计为可插拔式。
之所以采用第三方UI组件库进行封装,纯粹是为了减少开发的工作量,让精力能够投入到项目主要功能的开发上。 如何开发UI组件库是另外一个话题了,这里就不讲了。
表单组件扩展
表单组件越丰富,表单设计者可以应用的审批场景就越多,这取决于表单组件的生态建设。
扩展形式组件
很容易理解,在已有的表单组件的基础上,减少新的属性数组,并在此基础上扩展相应的组件能力。
表格设计
与表单组件一样,表单设计是判断表单核心能力的指标之一。 表单设计决定了最终生成表单的格式和风格。 它在表单设计者中的重要性是不言而喻的。
表单设计主要分为四个部分:表单布局、组件拖拽、表单样式、表单交互。
表格布局
可编辑表格组件-EditableTable
BPM表单设计器的表单布局基于一套自主开发的可编辑表单组件。 它的设计类似于Word中的插入表格,网上的一些文档也有类似的功能,实际开发中也借鉴了此类插入表格的交互效果。
在Word中插入表格:
自主开发的可编辑表格组件:
可编辑表格组件支持以下功能:
可编辑的表格组件还提高了单元格的可扩展性。 在这个cell的基础上,集成了可拖动组件Draggable,从而可以在cell中添加、移动、删除表单组件。
可编辑表格的设计思路
这是一个三行两列的表:
对应的数据结构是一个二维字段:
以及渲染表格的模板:
如果渲染静态表,当然只需要几个 merged、colspan、rowspan 的数组就够了。 但事实上,我们还需要做更多的事情。
拖拽框选择的实现
我们需要为每个单元格设置一个坐标,利用单元格的x,y数组来确定当前单元格在表格中的坐标,x,y数组非常重要,配合选中的数组和键盘风暴( mousedown、mousemove、mouseup ),您可以拖动选取框来选择单元格。
这里有一个技术点css表格合并单元格,如果框选包含一些合并单元格,要注意x、y坐标边界的处理。
问你一个问题:你认为上图中单元格框选择范围的最大坐标是多少?
对表行和列的操作
主要是通过不同的钩子函数来预估表格数据,控制单元格的colspan、rowspan、merged、mergeCellId等数组,实现预期的表格渲染。
就像拖动选取框一样,对于表格行列的操作,遇到合并单元格时,也要注意单元格数据估计的边界处理。
通过拖拽调整列宽或行高比较简单,这里不再赘述。