基于设计稿识别的可视化低代码系统实践

lxf2023-04-08 13:04:02

本文首发于「Shopee技术团队」公众号,探索更多Shopee技术实践

本文是基于 Shopee Supply Chain WMS(Warehouse Management System,仓库管理系统)团队利用前端代码系统进行降本增效的一次实践总结。

目录
1. 项目背景
    当前开发模式下的痛点
2. 思考破局
    业界方案对比
3. ASLINE 方案设计
    3.1 核心设计思想
    3.2 核心架构
4. 核心难点及解决方案
    4.1 设计稿组件智能识别
    4.2 布局转换
    4.3 接口字段与组件字段的匹配
5. 系统展示
6. 落地情况及后续计划

1. 项目背景

在 Shopee Supply Chain WMS 团队内部,经过近几年的沉淀,我们的设计团队、前端团队、后端团队之间形成了一套行之有效的协作方式

我们有如下基础资源和规范:

  • 前端基础组件库;
  • 前端业务组件库;
  • 前端和设计共同遵守的一整套设计规范,设计基于组件库的 UI,通过 Figma 输出设计稿;
  • 前后端目前的协同开发联调方式:通过 YAPI 在线平台,在接口未完成前,提前给出接口文档

当前开发模式下的痛点

然而,这些现有的组件、规范及流程虽然能一定程度上帮助我们更快产出页面,但是对开发效率提升的程度有限。

作为以 ToB 业务为主的仓库管理系统,前端页面中有大量的管理后台相关的页面,出现频率较高的就是以表格查询展示、表单输入、信息展示为主的列表查询页面和内容详情页面,如下所示:

基于设计稿识别的可视化低代码系统实践

并且,经过一两年的沉淀,我们的页面业务组件化程度较高,大部分页面都可以拆分成一个一个的业务组件模块。

我们有类似于 Element UI 的自研基础组件库。而业务组件是基于多个基础组件耦合了一定的业务属性和业务逻辑,进一步封装而成,由此渐渐也形成了一套业务组件库。

同时,在前后端接口联调环节,面对这些页面,前端需要耗费一定量的时间去匹配各个展示字段与接口字段,联调工作量较大。

总结起来,这里的痛点主要有:

  • 业务页面相似度高,且需求量大,存在大量列表查询页面、内容详情页面;
  • 前后端接口联调工作量大。

基于已有的组件库资源、设计规范、接口文档平台资源以及目前面临的痛点,我们在思考,能否有效将现有工具更好地串联起来?通过什么手段能更好地去提升开发效率?

2. 思考破局

针对上述痛点,我们的核心问题是:

  • 如何快速产出不含业务逻辑的前端页面?能否将设计稿直接转化成页面代码?
  • 如何有效降低前后端联调时间?

为此,我们自然而然地想到了当前比较火的低代码平台概念。基于痛点及诉求,我们预研了业界的一些优秀的同类低代码平台方案。

业界方案对比

下面对比了几个比较流行的业界低代码平台:imgCook、CodeFun、飞冰、H5-dooring 等。

方案imgcookCodeFun飞冰H5-dooring
端支持PC、移动端移动端为主PC、移动端PC、移动端
面向人群开发、运营主要面向开发开发、运营开发、运营
框架支持Vue、React、uni-app、React Native、H5 等 15 种开发规范Vue、微信小程序React、VueReact
二次开发体验1)支持可视化编辑
2)支持 schema 源码开发
3)支持样式配置、属性配置、数据源处理
1)支持简单的行为增加
2)支持简单的样式名修改
1)提供区块代码模版
2)代码只有组件示例,要大量修改
3)自动生成代码环境
1)支持可视化编辑
2)可扩展,但是基本无法支持复杂度高的页面二次编辑
设计稿支持Sketch、PSD、文件图片、FigmaSketch、Photoshop(内测)不支持不支持
生成代码质量1)较高的代码质量
2)可维护可迭代性高
1)合理的页面结构
2)较为精简的代码
1)合理的页面结构
2)UI 组件示例代码
3)基础组件会重复生成
1)不容易维护的绝对定位布局
2)存在部分代码冗余
支持拖拽××
接口对接×××
开源××