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

本文首发于「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 等。

👈左滑查看残缺表格

总体而言，不同的低代码平台有各自的特点和劣势，然而没有完全符合咱们需要的。最为外围的是，没法与咱们现有的工作流及已有的根底组件、业务组件库资源相买通。

咱们的诉求是：

• 须要反对 Figma 设计稿的辨认；
• 零碎可能和咱们自研组件根底库、业务组件库相结合，也就是生成的代码是基于咱们本身的根底组件库、业务组件库的；
• 可能无效和 API 对接，减速前后端联调；
• 可二次编辑导出的代码，领有足够的灵活性保障日后的优化与新的需要。

基于此，咱们决定研发基于 UI 设计稿辨认和主动 API 接口对接的可视化低代码零碎。

当然，这里有一点须要强调：咱们做的是 低代码 而不是 零代码 ，咱们的业务页面尽管类似度高，然而其中业务逻辑各不相同且非常复杂，咱们心愿这个零碎产出的只是 中段代码 ，能够了解为“半成品代码”，其目标只是帮实现前端页面布局与局部接口的联调对接工作，而咱们须要拿到这个 中段代码，二次开发，补充欠缺残余业务逻辑。

咱们设计的这个低代码零碎，指标是兼顾效率与灵活性。

3. ASLINE 方案设计

为此，咱们自研了 ASLINE 低代码零碎。

ASLINE，意为 Assemble Line 流水线，咱们心愿针对一些高频、量大、反复的页面，该零碎能像流水线一样疾速产出相应的高质量代码。

3.1 外围设计思维

该系统核心设计思维是充分利用现有资源，即：

欠缺的组件库 + 在线设计稿资源 + 在线接口文档。

外围流程如下：

1. 通过辨认设计稿，辨认设计稿中所用组件，组合成页面，主动生成基于 flex 的智能布局 UI 代码；
2. 通过接口文档，主动生成前端网络申请相干代码，主动匹配替换组件内字段；
3. 基于上述两个流程，补全生成大部分框架相干代码（Vue），导出残缺可运行的结构化页面代码。

该零碎提供的外围能力包含：

• 设计稿到页面布局及组件的智能辨认；
• 画布反对组件拖拽和智能吸附；
• 反对可视化配置调整；
• 组件和 API 接口字段主动匹配；
• API 接口局部代码主动生成；
• 代码主动生成合并及导出下载。

3.2 外围架构

再来看看咱们对整个零碎架构的形象设计：

整个零碎的交互操作都基于 低代码平台，通过三个外围算法：设计稿辨认算法、智能布局转换算法、API 与组件字段匹配算法将外围流程串联起来。

4. 外围难点及解决方案

该零碎的难点比拟多，这里围绕外围算法开展讲讲上面三点：

• 如何进行设计稿的辨认？
• 布局问题：辨认进去的组件如何实现基于画布的相对定位到导出时的流式布局转换？
• 如何实现接口字段与组件字段的匹配？如何晋升匹配准确率？

4.1 设计稿组件智能辨认

ASLINE 低代码零碎反对设计稿辨认，可能智能辨认出其中所应用到的对应组件。

这里有一个误区，咱们不是去间接比对图像之间的类似度，而是通过将图像抽象化并标准化为一个数字矩阵。最终比拟的，其实是两个通过标准化后的数字矩阵的类似度。

在组件辨认这一块，大家可能会想到图像识别，业界用的比拟多的支流计划是 Mask R-CNN 的依附机器学习的办法，然而咱们感觉这个我的项目没有必要搞得如此简单，不须要用到这种简单算法甚至须要用到机器学习的境地。

同时，还有一种不须要辨认，间接通过设计稿标记注明组件名称的计划。最终没有选取这个计划次要还是因为不具备很好的通用性（须要设计团队染指、也不利于推广到其余团队）。

因而，咱们折中选取了上面将介绍的这种，实现简略、处理速度快、准确率较高 的形式。

咱们能够通过 Figma 的 OpenAPI 获取一个用来形容设计稿所有元素的 JSON 文件，通过这个 JSON 文件，可能晓得文本的信息、各种元素的 CSS 信息、大小以及地位等。在拿到这些数据当前，能够通过提取出一些无效的特色，将这些特色转变为数字矩阵，通过数据的比照来辨认出对应的组件。

4.1.1 数据获取

咱们能够通过 Figma 的 OpenAPI 获取任意一个设计稿的 JSON 数据，接口为 https://api.figma.com/v1/files/:file_key/nodes，获取的返回数据格式大抵为：

{  
  name: 'Component Name',  
  lastModified: '2021-11-29T08:57:41Z',  
  version: '1334322378',  
  role: 'viewer',  
  nodes: {  
    id: '6:188',  
    name: 'Component Name/View',  
    type: 'FRAME',  
    children: [{  
      "id": "6:202",  
       "name": "bg",  
       "type": "RECTANGLE",  
       "blendMode": "PASS_THROUGH",  
       "absoluteBoundingBox": {  
          "x":1792.0,  
          "y":-762.0,  
          "width":114.0,  
          "height":32.0  
        },  
        "fills":[  
          {  
            "blendMode": "NORMAL",  
            "type":"SOLID",  
            "color":{"r":1.0,"g":1.0,"b":1.0,"a":1.0}  
          }  
        ],  
        "strokes":[  
          {  
            "blendMode":"NORMAL",  
            "visible":false,  
            "type":"SOLID",  
            "color": {  
              "r":0.85882353782653809,  
              "g":0.85882353782653809,  
              "b":0.85882353782653809,  
              "a":1.0   
            }  
          }  
        ]  
      }  
    // ... 还有 N 多个相似的节点  
    ]  
  }  
} 

nodes 中会蕴含着每个元素的各种各样的信息，这个信息量太多也太大，而且外面蕴含着大量冗余信息，所以下一步咱们须要进行数据清理。

4.1.2 数据清理

在获取设计稿所有的数据之后，咱们要进行数据清理的工作。这是因为在设计人员绘制设计稿的时候，有些文本或者元素信息可能应用的是 hide 属性，将其暗藏而并不是删除掉了这个元素。有时候可能多绘制了一些并没有显示成果的图层（相似于一个空的 div 元素），或者设计稿中标注了一些备注信息，这些对于设计稿的辨认工作都属于噪声（noise），所以第二步的工作是通过设置一些非凡规定（比方正则匹配以及辨认一些非凡的参数名称）来将这些噪声去除。

次要去除的内容包含：

• 剔除 visible 属性为 false 的元素；
• 剔除备注信息；
• 剔除对于展现无意义的元素。

4.1.3 特色数据提取

对于这一步骤的了解，能够设想一下，当咱们看到设计稿中有这样的一个组件：

接下来去组件的文档中寻找应该应用哪个组件，咱们找到了这个组件：

尽管两个组件内的文本信息不同，长度以及宽度都不雷同，然而咱们可能晓得它们其实是同一个组件。

这是因为咱们的大脑主动对组件进行了 抽象化（Abstraction），咱们将这两个图类似的特色都主动提取进去，进行标准化，而后就可能匹配到：这两个图片其实是一码事。

因而，咱们的组件匹配其实也是模拟这个过程的。在这里仅把提取文本作为特色来解说一下该过程：

• 首先，利用深度优先遍历将所有文本元素的信息都提取进去；
• 而后，生成一个二维数组，二维数组的列数为这个 Table 组件的宽度（也就是理论在设计稿中该组件的像素宽度），行数为这个 Table 组件的高度；
• 接着，将每一个文本元素在这个二维数组的地位都设置为 1，其余没有与文本元素坐标重合的二维数组的元素，值都为 0。

上面用一张图片模仿一下，彩色的局部就是二维数组中标记为 1 的中央，红色的则是二维数组中标记为 0 的中央：

接下来咱们就须要做标准化解决，也就是将文本元素的大小、数量，以及这个组件的宽与高，都依照肯定的比例进行标准化，变成上面这个款式：

左侧是标准化当前的组件，实在的二维数组是左边的样子，一个二维矩阵。理论是这样的（图片大小无限，理论的 0 和 1 会更多）：

4.1.4 数据压缩

失去了下面的二维矩阵当前，如果想要把它保留下来，十分消耗空间，因而该当将数据进行压缩。压缩数据的同时，还须要接下来可能间接进行数据比对，也就是须要一个 非凡无损压缩的算法。

能够发现这个 Table 组件的二维数组大部分都是 0，1 的局部是少部分，所以咱们先将这个二维数组变成一维数组，而后每 32 位分成一份，就能够发现，每一份外面的值都是一个 32 位的二进制。

咱们将这个二进制转为十进制的数字，如果该值为 0，则主动跳过这一份。如果值不为 0，则用一个对象来保留，key 值设为此份数据的 index，value 设为二进制转为十进制的值。这样咱们就将一个本来十分大的矩阵对象压缩成了一个小了十分多的对象。

压缩后的数据格式：

{  
  "Table": {  
    "matrix": {  
      "1": 127,  
      "2": 478,“10”: 1229332,  
      // ...  
      "528": 127,  
      "529": 2147483392,  
      "530": 8388607,  
      // ...  
    }  
  }  
}  

其中，“1”，“2”，“528”示意的是标准化后的坐标，代表这一块区域的信息不全为 0，而前面对应的数字则示意该区域的信息，咱们将本来的 01010101 展现改为了十进制展现。

4.1.5 组件比对

将数据进行压缩后，接下来进行数据比对。在实在的零碎中，数据库会保留着一份规范 Table 组件压缩后的数据，咱们在开始比对的时候，先把设计稿中的一个组件通过下面的转化，转成压缩后的数据，再把这个数据和数据库中保留的规范组件信息库进行比对。

比对的过程如下，通过上述计算后，能够失去设计稿中组件的数据：

{  
  "Table": {  
    "matrix": {  
      "528": 127,  
      "529": 2147483392,  
      "530": 8388607,  
      // ...  
    }  
  }  
}  

规范组件信息库中的某一个组件的数据：

{  
  "Table": {  
    "matrix": {  
      "528":300,  
      "529":2147483392,  
      "530":8388607,  
      // ...  
    }  
  }  
}  

能够看到，设计稿中组件的数据的 key 值有 528，这时候再去看规范库中的组件是否有 528，发现两边都有 index 是 528，值别离为 127 和 300，也就是说它们的二进制中有一些是不一样的。这时候能够利用位运算，就可能晓得哪些位是雷同的。

举个例子，利用与运算当前，失去 127 & 300 = 44，44 是一个二进制数转为十进制当前的值，其中 44 中有多少个数字 1 就代表了两个片段的类似度是多少，那这时候怎么能力晓得 44 的二进制中有多少个位数是 1？

咱们能够抉择将 44 转为 32 位的二进制，而后遍历一遍来获取一共多少个位为 1。但更加快捷的办法是，44 的 32 位二进制中，是 1 的位数必定是小于 32 的，那么咱们利用一个非凡的位运算办法 i & (i-1)，利用这个位运算，就可能将一个二进制最右侧的 1 去掉。

为什么 i & (i-1) 能革除最左边的 1 呢？因为从二进制的角度讲，n 相当于在 n-1 的最低位加上 1。44 的二进制为 101100，43 的二进制为 101011，44 & (44-1) = 40，40 的二进制为 101000，也就是比 44 的二进制少一位。所以能够利用循环让一个数字与上个数字减 1，晓得这个数字为 0。

利用此形式，比对的次数肯定小于 32 次，咱们也就能够基于此来进行算法的优化。在通过此办法循环遍历所有组件后，选取类似度最高的，即可失去比对后果。

以上就是基于图像的信息来辨认一个组件的全过程，大抵分为 5 个步骤：

1. 数据获取；
2. 数据清理；
3. 特色数据提取；
4. 数据压缩；
5. 数据比对。

通过上述 5 个步骤，即可找到类似度最高的组件。这种计划的益处在于不须要特地大的样本量，相似于深度学习训练后的模型的函数，咱们找到了毛糙版的函数。这种计划的辨认速度快，而且文本信息的提取与组件辨认是在一起获取的，不须要分成两个局部，这样进一步提高了效率。

然而这种计划有时候必定也会有辨认不精确状况，而且这种计划因为是人工定义的一些特色数据（比方下面的例子，咱们就将特色数据定为文本信息，还能够是边框等信息），无奈笼罩得过于全面，因而，咱们基于辨认也有一整套的进化降级计划：

当然，这里还有一些问题须要解释一下，譬如为什么不间接用一个 ID 在设计稿中明确标识是哪种组件？为什么肯定要去用算法去辨认？这里有几个起因：

• 思考到团队外部 Figma 账号与相应设计资源的权限调配，若要求设计师明确标识每一个组件，并带上特定的 ID，将额定减少设计工作量，同时不太利于向其余团队推广这个工具；
• 基于现有的辨认形式，假如新增一个组件，无需 UI 侧同步新增这个 ID。

基于以上现状，咱们设计了如此一种辨认的形式。而且它是通用的，基于任何组件都能够这样去做。

4.2 布局转换

许多低代码平台在画布上进行展现的时候，因为要不便计算和拖动，都是基于相对定位的，最终产出的页面代码应用的布局形式也大部分是相对定位。

然而在实在的业务代码中，HTML 代码都须要有层级构造，并且就目前而言，少数利用 flex 进行弹性布局。所以咱们须要一个将相对定位的组件转换为 flex 弹性布局的算法。

咱们的做法是：

• 通过各个组件地位计算，主动生成带有层级构造的 HTML 代码；
• 通过组件之间的地位关系，优先以“行”构造进行划分，其次以“列”构造进行计算，生成基于 flex 布局的 HTML/CSS 代码。

如何得悉布局的行列信息？咱们采纳的是 投影法，以这样一个布局为例子：

它由 3 个业务组件 形成，每一个即为一个 flex item。那么，如何在转化的过程中晓得它的嵌套构造——得悉它有 2 行，其中第一行有 1 个元素，第二行有并排的 2 个元素呢？

先从左侧往右看，假如一束程度光打过来，投影在墙上的后果——不间断彩色块的个数，即是能够分隔的行的数量：

基于上述后果分隔失去的行，再从上往下投影，又能够失去每一行中有多少列。

最终，咱们会将本来基于相对定位的布局，转换为基于 Flex 的布局，相似于这样：

<div class="container">  
  <div class="row-1">  
    <PageHeader />  
  </div>  
  <div class="row-2">  
    <div class="column-3">  
      <ProTable />  
    </div>  
    <div class="column-4">  
      <TrackingHistory />  
    </div>  
  </div>  
</div>  

.container {  
  display: flex;  
  flex-direction: column;  
}  
.row-2 {  
  margin-top: 12px;  
  display: flex;  
}  
.column-4 {margin-left: 20px;} 

对于整个 container 而言，咱们会将它设定为一个竖向排列的 flex 布局，设定 display: flex 与 flex-direction: column。

而 container 容器之下，则是根据上述的投影剖析后果，设定 row 信息（行信息），每个行容器内设定 flex-direction: row，再依据每行内的垂直投影剖析失去行内的 column 散布，同时依据理论物理排布，失去每列之间的间距信息，从而汇总失去整体的 flex 布局代码。

4.3 接口字段与组件字段的匹配

当辨认出了设计稿中相应的业务组件，并将其渲染在页面上之后，ASLINE 低代码零碎还提供一种能力，可能将每个业务组件与一个接口进行关联匹配，通过输出关联的接口文档 URL，主动生成前端网络申请相干代码，主动匹配替换组件内的字段。

这里咱们次要做了几件事：

第一，当用户提供了对应业务组件的接口文档 URL，零碎就能帮忙生成申请相干的代码，节俭局部工作量。

第二，实现了前端页面展现与接口字段的匹配。这是什么意思呢？譬如一个表格组件中，某字段在前端展现为 start time，后端接口返回给前端的字段可能用的是 start_time、begin_time 等模式示意。这里，算法要做的事件，就是将前端展现的字段与后端返回的字段进行匹配，将它们正确地关联起来。

这里的整体流程：

1. 选中组件后，能失去组件的字段数据；
2. 输出接口文档申请参数，将文档参数和组件字段数据传到咱们的 API 解决服务；
3. API 解决服务失去接口文档申请参数，拉取用户输出的接口文档数据；
4. 组件字段数据和接口文档数据进行匹配，通过类似度算法计算出匹配度最高的接口字段；
5. 把组件字段替换为匹配接口文档后的字段值；
6. 返回匹配接口文档后的组件数据、API 接口数据；
7. 零碎接管到响应数据后，将匹配好的组件数据更新到页面上；
8. 用户可对匹配后的字段，进行人工二次确认及调整。

其模式大略如下，对于咱们这样一个业务组件 ProHeader：

右侧数据面板如下：

通过输出接口文档对应该接口的 URL，咱们能拉取到接口相干信息，Label 列示意的是前端展现的字段文案，而 Prop 列则是通过智能匹配后，展现字段与接口字段的匹配后果。

而对于这样一个 PageHeader 组件，通过辨认及接口匹配后，导出时会主动生成这样一段代码，以 Vue 我的项目为例，大抵的伪代码如下：

<template>  
  <SPageHeader  
    // 一些组件的 props 入参  
    :infoSchemas="schemaProps.infoSchemas"  
    :infoValues="infoValues"  
    :titleInfo="titleInfo"  
  >  
  </SPageHeader>  
</template>  
 
<script>  
import {Vue, Component} from 'vue-property-decorator';  
import {SPageHeader} from '@/ssc-vue-ui';  
import request from '@/utils/request';  
  
// 通过剖析接口文档生成的申请入参 interface  
interface InterfaceGetCcOrderDetail {// ...}  
  
// 主动生成申请接口相干代码  
export const getCcOrderDetail = async (params: InterfaceGetCcOrderDetail) => {  
  const res = await request.get(  
    '/api/test/xxx/xxx/get_xx_order_detail',  
    {  
      params: {...params,},  
    },  
  );  
  return res;  
};  
  
@Component  
export default class SPageHeaderComponent extends Vue {  
  titleInfo = {// 通过辨认设计稿失去的一些组件默认文案};  
  
  // basicInfo label 列表，依据设计稿和接口文档，实现组件的理论展现参数与接口文档字段的匹配，及一些业务信息  
  infoSchemas = [{ label: 'Source From', key: 'source_from', enums: 'CycleCountSourceFrom'},  
    {label: 'Source ID', key: 'source_id'},  
    {label: 'Type', key: 'cc_type', enums: 'CycleCountType'},  
    {  
      label: 'Operate Function',  
      key: 'cc_operate_function',  
      enums: 'CycleCountSkuCCOperateFunction',  
    },  
    {label: 'DynamicCycle Count', key: 'is_dynamic_count', enums: 'YesNo'},  
    {label: 'Blind Count', key: 'is_blind_count', enums: 'YesNo'},  
    {label: 'One By One', key: 'is_one_by_one', enums: 'YesNo'},  
    {label: 'Create Time', key: 'create_time'},  
    {label: 'Creator', key: 'creator'},  
    {label: 'Cycle Count Method', key: 'cc_method', enums: 'Express'},  
  ];  
  // 简略的初始化逻辑，发送申请，渲染组件  
  mounted() {this.getDetailInfos();  
  }  
  async getDetailInfos() {  
    try {const res = await getCcOrderDetail();  
      console.log(res);  
    } catch (error) {console.log(error);  
    }  
  }  
}  
</script>  
 
<style lang="scss">  
// CSS 相干代码  
</style> 

蕴含了整个 Vue 文件的各个局部，组件入参、接口申请、组件渲染等等。

当然，这里只是一个业务组件，对于残缺的页面而言，咱们还会基于单个组件，再有一个 index.vue 聚合页面上的所有组件，并且基于 flex 布局实现相干内容的排版。

5. 零碎展现

接下来简略展现一下整个零碎及其外围步骤。

一开始进到首页只有一个输入框，只须要填入对应的 Figma URL。

在对应的 Figma 页面上，选取一个咱们业务中常见的列表页，将其 URL 填入零碎的输入框中即可。

实现辨认后，零碎会给出以后所辨认出的业务组件列表，有一个用户二次确认调整的过程：

再点击下一步，即可进入主编辑区域。在画板上失去咱们所辨认出的组件：

这里分为：

• 可拖拽组件区域：能够对画布内容进行减少，对于一些未被辨认的组件能够从这里拖进画布；
• 操作面板区域：一些对画布操作的惯例工具栏，譬如撤销、回退、辅助线等等；
• 画布区域：能够调整布局，删减组件；
• 二次编辑面板：对每一个组件进行深度调整，关联接口等操作。

最初，调整结束，点击右上角导出代码，即可取得每个业务组件独自的代码，和这个页面的残缺代码。

6. 落地状况及后续打算

这里还是有必要再强调一下：该平台只是低代码平台，而不是零代码平台，零碎帮咱们实现的，只是页面布局、接口联调等一些繁琐的重复性工作。拿到零碎导出的代码后，咱们还是须要基于这部分中段代码，持续补齐一些简单业务逻辑。

这是咱们从本人的业务场景登程，思考理论日常工作中的痛点，而实现的一套无效加重局部反复机械劳动的零碎工具。

目前，此零碎曾经接入了 Shopee 供应链下基于 Vue 框架的多个子项目：

• 可适用范围：目前全辨认加能用的半辨认大略占设计稿的 30%-35%，次要散布在列表页和详情页；
• 对于这些列表页和详情页，从目前接入应用的状况而言，业务组件的辨认成功率可能达到 92%，只有少部分状况须要手动批改，或者间接在页面进行拖拽；
• 对于实用页面，均匀可节约 80% 的开发工夫（单个列表页从 0.5 – 1 个工作日升高至 1 个小时）。

当然，ASLINE 可能显著晋升开发效率，升高开发成本，然而也存在肯定的局限性，须要各种标准 / 组件库作为撑持。并且后期开发的工作量不低。

对于后续瞻望，咱们曾经开始着手适配不同组件库及开发框架（React），并且引入智能学习，进步辨认准确率、接口字段匹配成功率。

同时，咱们也在画布的易用性、体验交互上一直进行优化，一直减少反对的组件数量。咱们冀望在无设计资源投入的状况下，反对疾速拖拽组装罕用页面，服务于一些非前端同学，产生更大的业务价值。

本文作者

Coco，前端工程师，来自 Shopee Supply Chain 团队。