京东低代码平台：浅谈水滴拖拽画布的设计与实现

水滴低代码平台简介

京东水滴平台面向企业内部后台管理系统场景，提供可视化搭建等低代码配置、构建及部署能力。

水滴画布作为水滴低代码的核心能力之一，具备灵活、易用的特点，用户可以通过简单拖拉拽的方式，在不需要具备前端知识的前提下，即可搭建出理想的页面。下面将为大家介绍水滴低代码画布的设计与实现。

低代码画布的概念及类型

画布的概念： 用户可以向画布中添加物料，并对物料进行拖/拉/拽布局，搭建出自己想要的页面。
这个概念延伸于艺术家的画板，画家在绘画的过程中，会将颜料进行调色，并在画布中进行绘制。而低代码平台用户在页面搭建的过程中，需要选择相应的物料，在画布中使用拖拉拽的方式放置到正确的位置，并对物料进行一些属性配置来达到最理想的展示效果。用户的搭建过程与艺术家的绘制方式非常的相似，因此这个概念也来源于此。

画布的类型： 低代码画布可以根据业务场景的不同可分为多种类型，目前主要的类型有以下几种：

页面类型：用于网页的搭建，包含 web 页面及 H5 页面
流程类型：用于流程图的搭建，包含审批流程及函数流程
数据大屏类型：用于数据报表与可视化分析工具的搭建

水滴低代码画布目前主要用于页面的搭建，也是本次需要介绍和讲解的画布的类型 - 页面类型。

主流低代码画布的调研情况

在开发水滴画布之前，就京东内其他低代码平台和国外的主流低代码平台 Retool 做了调研。下面将对这些低代码平台的画布能力做一个分析，并和水滴画布进行对比。

画布特点	京东内其他平台	Retool	水滴
面向用户	前端开发	普通用户	普通用户
是否可拖动	✅	✅	✅
宽高拖拽	宽度	宽度	宽度 + 高度
布局	block	grid	absolute + grid
配置复杂度	复杂	简单	简单
UI还原度	中	中	高
上手成本	高	低	低

通过调研的情况和一些能力的对比，我们可以发现：京东内其他平台使用了 Block 块布局、Retool 使用了 Grid 网格布局，这些布局特性在带来页面自适应能力的同时，也会丢失物料自定义宽高的适配能力，使得一旦需要固定宽高和自适应内容高度的时候，就会让展示的效果不够理想。
京东内其他平台和 Retool 都对此做了一些弥补和取舍，例如京东内其他平台将前端的布局配置展示了出来，让用户自己去调整，在增加了布局场景的同时，也提高了非前端用户的使用门槛。而 Retool 则在精准搭建方面做了一部分的妥协，为了提高易用性，做了一些强制性的约束。

水滴画布的研发目标

水滴画布面向的人群有运营、产品、测试、开发人员等，这些人群中有些是有前端的基础，而大部分都不具备前端的知识，所以在设计画布的过程中，要尽可能地降低用户的学习成本和上手成本。于是，我们选取了以下几种功能特性，并做出了开发的目标：

布局： absolute绝对定位布局 + grid网格布局
拖拽：
1. 支持物料宽度和高度的拖拽、缩放；
2. 支持物料在画布中灵活定位
目标：
1. 简单易用 - 拖拽搭建无限制，自由灵活；
2. 操作流畅 - 保证用户频繁操作过程中的页面性能；
3. 覆盖面广 - 支持展示、内容、工作台、管理等 B 端常见场景。

水滴画布的设计方案

水滴画布 drip-layout 给出了一种新的低代码画布的设计方案，将搭建层和渲染层分离，并且通过算法转换层来适配搭建页在不同屏幕下的展示效果。

首先在搭建层获得物料的在页面中的定位信息 - layouts 和物料的个性化布局配置 - config。
通过算法转换层来适配页面在不同屏幕下的位置/宽高信息 - layouts。
渲染层根据算法转换后的layouts信息，对页面内的所有物料进行渲染、展示。渲染层的画布会在浏览器视口大小发生变化时，进行回流到算法转换层，重新布局计算、动态适配页面大小。

下图展示了水滴画布的方案设计：

在搭建层的物料拖拽和缩放的交互上，使用了 react-grid-layout 底层库，并将 grid 网格的 row col 大小都设置成了 1，使得以绝对定位的方式拖拉拽后的物料定位信息 layouts，单位都精确到了 1px。最后在渲染层，根据真实页面的宽高，对渲染区域进行 grid 网格划分，并根据计算层转换后的位置信息 layouts，将物料使用 grid 的方式进行布局渲染。

水滴画布的实现架构

下图展示水滴画布的一些底层库的选取，和提供的一些能力，以及在计算层使用的一些主要的算法：

水滴画布计算层实现算法

容器自适应物料高度 - moduleResizeObserver

在大多数场景下，物料在页面中需要能够根据自身的真实高度进行展示，例如表格的一页数据全展示、表单内容的动态删减导致模块高度变化。这些动态的高度，都需要实时地体现在画布中，那么就需要动态监听物料的框高的变化，并将真实宽高展示在画布中。
这里使用了浏览器的 ResizeObserver api，对物料的宽高实时监听，下面是实现的逻辑代码：

页面扩张情况自适应 - 固定宽度模块的收缩对相邻模块的影响

在一些大屏幕下，页面的宽度大小是要比画布中的宽度要大，画布就需要被拉伸扩展。在这种情况下，画布内的弹性模块就可以直接被等比拉伸，固定模块由于宽度需要保持固定，就会空出空间（下图紫色区域），那么相邻的模块就会受到影响。受到的影响主要有以下几种情况：

相邻为弹性模块，可以被直接拉伸，来填充空间
相邻为固定模块，且对齐方式相同，则会被影响，因此需要平移相同的距离
相邻为固定模块，且对齐方式不相同，则不会被影响
【ps】: “对齐方式”是用来确定在页面发生形变的情况下，模块在画布的水平轴上的对齐方式

由于模块之间的影响具有传染性，通过深度优先遍历的方式，处理了所有固定模块，及其相邻的模块，来消除固定模块的收缩带来的影响。

页面压缩情况自适应 - 固定模块的拉伸对相邻模块的影响

在一些屏幕下，页面的大小是要比画布中的宽度要小，画布就需要被压缩。画布内的弹性模块可以被直接等比压缩，固定模块由于宽度需要保持固定，就会发生一定比例的膨胀（下图紫色区域），那么相邻的模块就会受到挤压。相邻模块受到的影响主要有以下几种情况：

相邻为弹性模块，则会被直接压缩
相邻为固定模块，由于宽度固定，受到挤压之后，需要进行等距离的平移
所以当前行的整体宽度不够，那么右侧的模块需要进行换行处理
【ps】: “对齐方式”是用来确定在页面发生形变的情况下，模块在画布的水平轴上的对齐方式

由于模块之间的影响具有传染性，通过深度优先遍历的方式，处理了所有固定模块，及其相邻的模块，来消除固定模块的拉伸带来的影响。

边界处理

由于 JavaScript 在进行数值计算时，存在精度丢失的情况，可能会导致两个紧密相邻模块的计算结果，在定位上出现交叉的情况。这种定位交叉的情况，又会在画布的边界碰撞检测处理下，出现画布布局错乱的问题。但是如果使用保留 n 位小数的方式进行精度计算，又会导致相邻模块之间由于取整导致小数位丢失，从而模块间会出现缝隙的视觉效果。
精度丢失计算场景：A.x + A.w === B.x => 1.3 + 1.6 === 2.9 => 结果：false
因此水滴画布做了一些假设：如果两个模块边界之间的差距小于 1px，则对两个模块的边界之间进行粘合，来消除 JavaScript 精度丢失带来的影响。