【第2357期】前端物料在低代码研发模式下的探索

前言

今日前端早读课文章由阿里@金禅授权，由公号@金禅分享。

@金禅，阿里巴巴前端技术专家，是集团前端委员会中后台物料生态负责人，集团低代码引擎共建小组核心成员，目前专注于前端物料生态、低代码研发领域。

正文从这开始~~

“Low-Code(低代码)” 最早是由 Forrester 提出的，在近几年又赢来了一轮爆发，2021 钉钉 6.0 发布会推出了“宜搭 YIDA”，2020 年底腾讯云推出了“微搭低代码 WeDa”，2019 年百度开源了低代码研发框架 “AMIS”；低代码研发平台的融资消息越来越多，仅是 2021 年 3 月就有 5 起千万级融资。

低代码的本质是什么

我们知道技术的本质是将 idea 落地，技术面向的用户一般是开发者，而低代码或者零代码其实也是一种技术手段，但低代码面向的用户则不一定是开发者，它的目标用户是想要实现 idea 的任何人，低代码是实现 Citizen Developer(全民开发者) 的关键。低代码通过抽象和交互升级隐藏了很多技术细节，抹平了开发者和非开发者的知识差异，让非开发者也能亲手实现自己的 idea，这就是赋能，因此低代码的本质其实是跨专业能力的赋能。

为什么低代码再次兴起

低代码领域的巨头 OutSystems，早在2001年就已经创立，Mendix 创立于 2005 年，那么为什么低代码之前没火起来，最近才越来越火了呢？我认为有两方面的原因：

需求井喷

互联网发展到现阶段，C 端人口红利逐渐消失，野蛮生长的时代已经过去，企业必须精细化运营才能保持增长，同时越来越多的传统企业在向互联网转型，这些都带来了井喷的中后台业务需求。而中后台业务相对于前台业务有一个特点，中后台业务的 UI 更加模式化，更适合通过低代码搭建的方式来生产。低代码越来越被需要了，这是低代码再次兴起的原因之一。

基础技术趋于成熟

任何技术都有其成长周期，低代码研发平台所需的核心技术也经过了漫长的发展趋于成熟，特别是对于前端来讲，我认为前端组件的出现和基于组件的研发链路的广泛应用为低代码的兴起提供了最底层的保障。

前面提到低代码的本质是赋能，抹平非开发者的知识差异；我们可以试想一下，在前端组件出现之前，要实现一个页面，开发者需要编写 HTML、CSS 代码，这个效率是很低下的(这也是前端组件出现的原因)，如果此时有一个低代码研发平台，非开发者要拖拽 HTML 标签、配置 css 来搭建一个页面，这个效率可想而知，这样的低代码研发平台也达不到赋能的目的。而前端组件的出现则大大缓解了这个问题，前端组件并不是一个纯技术的概念，而是从 web 应用的视角被设计出来的一系列可复用单元，非开发者也能够很容易理解组件这个概念，因此组件的出现和广泛应用为低代码能够真正实现赋能提供了保障。

我们围绕前端物料的积累

从前端组件到前端物料

前端组件的出现大大的提高了前端开发效率，在实际业务中，我们根据组件的复用粒度和使用方式对组件及其衍生物进行了更细的划分：

基础组件（Basic Components）：前端领域通用的基础组件，阿里经济体前端委员会官方指定的基础组件库是Fusion Next/AntD；

图表组件（Chart Components）：前端领域通用的图表组件，有代表性的图表组件库有BizCharts；

业务组件（Business Components）：业务领域内基于基础组件之上定义的组件，可能会包含特定业务域的交互或者是业务数据，对外仅暴露可配置的属性，且必须发布到公域如阿里NPM；在同一个业务域内可以流通，但不需要确保可以跨业务域复用；

布局组件（Layout Components）：前端领域通用的用于实现基础组件、图表组件、业务组件之间各类布局关系的组件，如三栏布局组件；

区块（Block）：一系列业务组件、布局组件等组合而成的代码片段，不对外提供可配置的属性；区块内部具备完整的内部样式、事件、生命周期管理、状态管理、数据流转机制，能独立存在和运行，通过代码片段的复制实现跨页面、跨应用的快速复用，保障功能和数据的正常；

模板（Template）：特定垂直业务领域内的业务组件、区块可组合为单个页面，或者是再配合路由组合为多个页面集，统称为模板；

上述可复用单元统称前端物料。

前端物料的演进

物料开发优先？

前端物料是构成前端项目(页面)的可复用单元，那么在一个前端项目的迭代周期中，我们期望的是前端同学拿到了设计稿首先就先能分辨页面的哪些部分可以用现有物料来做，哪些部分要新开发物料，所以在页面开发前先开发缺的物料，或者物料开发和组件开发由不同的人同时进行。

然而实际情况是怎么样呢？分析设计稿中哪些部分可以用现有物料来实现这部分是必要的，对于新物料的开发在很多情况下都会被忽略掉而直接进行页面的开发；前面说过，前端物料是可复用单元，但是对于一个新项目或者单个页面来说，要将页面中可能会复用的部分抽象成一个独立的物料再引入页面开发，整个流程是被拉长了的，效率反而会降低，特别是对于一些人力不足的紧急项目(在阿里很常见)来说，物料开发先于页面开发的效益是不高的。

物料开发优先除了会降低单个页面的开发效率还可能会出现新开发的物料无法在其他地方复用，因为开发者直接从设计稿抽象出新物料是未被验证可复用的，这样的话不仅降低了单个页面的开发效率，对于项目整体的研发效率也没有提高。

那么是不是一定不能物料开发优先呢？其实也不是，如果你对自己的抽象能力非常有把握，能确定新物料能够在项目中被复用，并且项目有足够的人力保障，那物料开发优先可以很好的提效，但是对于大多数情况来讲，物料渐进式演进是更好的选择。

物料渐进式演进

我们在写代码的时候，遇到重复的逻辑会将其抽象成一个方法在不同的地方调用；对于前端物料也是同样的，我们可以在遇到重复界面的时候先在项目中对其进行抽象得到一个项目内可复用的模块，当遇到这个模块需要跨项目复用的时候我们再将它独立出来成为一个前端物料，这就是物料渐进式演进的过程。

基于前端物料的研发链路提效

研发链路分析

在一个前端项目迭代周期中跟物料相关的部分，除了物料的沉淀，物料的挑选和消费会占更大的比重，那么要如何对整体研发链路进行提效呢？我们先来分析一下整个过程中有哪些环节：

如上图所示，开发者最多会经历基础物料->团队物料->物料中心->搜索引擎->物料开发->物料沉淀->物料消费这些环节，除了搜索引擎不可控，其他环节的提效都可以算是研发链路的整体提效。

基础物料

开发者第一步就会去看看基础组件里是否有合适的，如果有的话就直接消费了，所以基础物料的丰富度、文档和品质非常重要；

团队物料

如果没有合适的基础组件，开发者会去看看团队内是否沉淀过匹配的物料，这个过程就因团队而异了，有些团队没有公共的地方沉淀物料，他们只能去团队群里问问；大一点的团队把内部沉淀的物料记录在一个语雀文档里，方便团队内部复用；再大一点的团队可能会建设自己的物料站点，将物料都放在线上站点，这样团队内部的同学可以更快地判别是否有合适的物料，也能更方便的查看物料文档，但是物料站点的搭建和维护都有不小的成本；因此物料站点也是一个可以提效的点；

物料中心

如果团队内部也没有合适的物料，开发者可以去物料中心看看，别的团队有没有沉淀类似的物料，用户从打开物料中心到找到合适的物料这个过程，都是物料中心要优化提效的点；

物料开发

如果上述过程都没有找到合适的物料，那么开发者需要自行开发一个物料出来，帮助用户快速开发物料也是一个提效的点；

物料沉淀

开发好了物料，为了方便下次复用，需要沉淀下来，帮助用户沉淀物料也是对研发链路的提效；

物料消费

物料消费也是可以提效的，例如我们把物料的 API 和 Demo 写的更加丰富、易懂，可以方便开发者更快上手，这也是对整体研发链路的提效；

提效方案

丰富官方物料

开发者在实现一个页面时第一个想到的就是官方物料，官方物料是由专人维护的通用精品物料，可以给业务开发提供质量保障，所以官方物料要在保证质量的前提下尽可能的覆盖更多的场景。

帮助业务自建物料体系

官方物料再全也不可能覆盖所有场景，一定会有业务物料被开发出来，那么业务就会存在对业务物料的生产、管理、共享、消费整套体系建设的诉求，因此我们提供了一系列的工具和平台能力，帮助用户快速地自建自身的物料体系：

物料生产与 demo 托管

以 build-scripts 为底座，通过 iceworks add component 会自动生成符合物料规范的组件代码目录结构，通过 tnpm start 可在本地启动服务调试组件代码和 demo/xx.md 中的组件 demo；这背后起作用的其实是 build-plugin-components 这个插件，该插件除了启动本地调试服务外还能够将 demo 目录下的 md 文件以及 README.md 中的组件 API 说明聚合打包成一个完整的 HTML 页面到 build/index.html；

再通过 tnpm publish 将组件编译后的文件包含 build 目录总的 demo 发布成 tnpm 包，当组件被同步到物料中心时，物料中心会自动获取 tnpm 中的 demo 进行托管并提供 demo 预览功能；

物料管理

用户开发好物料后可通过执行 iceworks sync (也可以使用物料中心 OpenAPI 或 sdk 自行同步)将物料同步到物料中心的指定站点，用户可在一个站点下管理业务沉淀的多个物料，还可以在物料中心挑选物料添加到自己的站点；

物料站点提供物料版本管理、物料 demo 预览、物料 demo 在线切换主题等能力；

物料消费

物料站点还提供物料源接口，用户可通过这个接口获取站点下所有物料进行消费(iceworks 客户端可集成物料源接口可视化地展示用户站点的物料)；

前端物料低代码化演进

低代码引擎原理

协议

《中后台搭建协议》

《中后台组件描述协议》

核心模块

渲染模块——所见即所得；

编排模块；

• 设计器——拖拽搭建；

• 配置面板——组件属性配置；

• 入料模块——组件接入；

• 出码模块——搭建产物转代码；

前端物料如何被引擎消费

一个源码组件要在低代码引擎中使用需要满足三个条件：

• 组件的 umd 格式资源；

• 组件的默认搭建协议 schema，下文简称 snippet；

• 组件的低代码描述协议 schema，下文简称 configure；

组件的 umd 资源和默认的搭建 schema 是为了让组件能够在引擎中在线的渲染出来；

低代码描述协议则是为了让引擎识别出组件的 props 以及每个 prop 对应的配置面板描述，当用户选中组件时可以展示出组件的配置项，以及不同配置项对应的配置面板。

从上图可以看到，组件并非单个独立被低代码引擎消费的，而是以集合的形式被低代码引擎消费，因此我们制定了《中后台物料资产包协议》对组件集合的描述进行规范。

前端物料低代码化演进

对于准备探索低代码的业务来说，我们要提供一套开箱即用的低代码基础组件库，用户可以通过这套组件库来属性低代码研发模式，熟悉低代码物料的编写，快速判断自身业务是否适合使用低代码；

对于已经准备使用低代码的业务来说，我们要提供一种方式，让业务尽可能低门槛地实现物料低代码化，因此我们在开发源码物料的脚手架体系下提供了一个插件，支持一键开启物料低代码化；

对于物料中心上的存量源码组件来说，物料中心提供在线的方式让源码物料低代码化，并且提供可视化编辑器来配置物料的可配置属性。

入料模块实现原理

入料模块是前端物料低代码化的关键，前面提到源码物料+组件描述协议协议 schema 就能够被低代码引擎消费，入料模块就是解析源码组件来自动生成组件描述协议 schema 的。为了尽可能提高解析成功率的同时兼顾解析效率，入料模块提供了两步解析：静态解析和动态解析，静态解析不成功才进行动态解析。

静态解析

静态解析就是通过 npm 包从组件的入口文件开始直接解析文件得到 AST，然后通过 AST 找到组件代码中对应的 props 列表及其默认值；这种解析方式效率会比较高，但是成功率不高，因为不同的组件的编码方式差异较大，特别是复杂组件要直接通过编译后的代码正确地解析出组件的 props 比较困难。

动态解析

动态解析相对于静态解析成功率会搞一些，它的原理是直接提供一个沙箱环境将组件完整的加载进来，获取到自己的实例后通过组件的属性来得到组件的 props 信息。

低代码资产管理解决方案

低代码资产管理解决方案是「基于物料的研发提效方案」的延伸，在其基础上根据低代码研发链路的特点提供了能力升级，整个方案是渐进式演进的。

源码组件低代码化

组件开发环节低代码化调试

提供 build-plugin-lowcode 插件：

• 结合入料模块实现组件代码解析自动生成初始化 material-meta.json 文件；

• 集成低代码引擎提供极简搭建平台实现 material-meta.json 本地调试功能；

• 打包组件低代码 demo 成一个完整的 HTML 到 build/lowcode/index.html 发布到 tnpm 上，物料中心可自动同步物料的 LowCode demo 提供在线预览服务；

在线低代码化配置

• 物料中心提供接口可在线解析组件 npm 包自动生成初始化 material-meta.json 文件；

• 物料站点提供 material-meta.json 在线编辑能力；

物料资产包管理与交付

物料资产包 umd 资源构建

• 将资产包中所有业务组件构建成一个大 umd 资源，减少资产包中资源数量；

• 可选择 fusion 主题参与构建；

• 将资产包中的所有物料的 material-meta.json 聚合成完整的资产包数据结构；

物料资产包交付

• 将资产包发布到 tnpm，通过 tnpm 来实现版本管理，低代码引擎可以引用物料资产包的 tnpm 包来设置资产；

• 将资产包发布到 cdn，低代码引擎可以直接引用资产包 cdn 地址来设置资产；

搭建布局体系

当引擎准备好了，物料也低代码化了，那么我们的低代码研发平台就能够实现跨专业能力的赋能了吗？其实我们还缺一个东西，那就是搭建布局体系。搭建布局分为绝对布局和相对布局，绝对布局就是组件在设计器上拖到哪里就是哪里，而相对布局则是根据组件拖动的位置相对于父容器或者兄弟组件的位置进行排布，然后通过调整样式来实现布局。

绝对布局对于非设计师来说，很难将一个页面中组件的大小，组件之间的间距控制好，最后搭建出来的页面会不太好看，如果绝对布局提供了标尺和自动吸附能力这个问题可能会有所缓解，但对于非设计师来说要搭建出一个好看的页面难度还是很大，并且由于绝对布局没有父子关系，类似切换 tab 展示不同内容这样的功能就没办法实现了；这是使用绝对布局会出现的问题，而直接相对布局问题会更大些，相对布局要求搭建者写 css 样式，这个学习成本会很高也就很难实现赋能了。

直接使用绝对布局或者相对布局都有些问题，因此我们需要实现一套不需要写 css 样式，也不需要有设计相关的知识就能够搭建出“默认好看”的页面的布局体系。

搭建体校利器——自然布局

自然布局的理念是提供“文档排版式的搭建体验”，对于搭建的用户来说，因为职能上的知识差异会对搭建布局体系有不一样的要求；但是对于文档排版来说，不同用户之间的差异就很小了，不管是产品经理、设计师还是研发同学，我们写的文档不会说谁的排版比谁的好看很多，我们使用语雀写出来的文档默认就是“好看”的，那么搭建是否也能提供类似的方案呢？自然布局就是希望提供这样的搭建体验。

自然布局抽象出了常用的页面布局方式，可以直接通过配置的方式选择不同的布局方式；

自然布局通过给拖入组件自动包裹段落，段落间的间距由主题来控制这样就保证了整个页面段落的排布不会显得杂乱；

段落内组件的间距由字号或者组件高度动态调整，并且段落还提供了常见的段落内容排版方式；

段落内还可以通过“编组”的能力，将两个或多个组件打包起来进行排版；

通过自然布局提供的上述能力，一个非研发或者非设计的同学能够高效的搭建一个页面出来，这是让低代码搭建平台能够真正实现赋能的关键。自然布局还在持续迭代中，目前覆盖的场景有限，希望后续能够覆盖更多的场景。

从研发链路看问题——前端物料即设计物料

前面的内容不管是源码物料还是低代码物料的提效都还是站在开发的视角去考虑的，我们试着从全局视角来看整个研发链路中还有什么问题可以通过物料来提效的。

我们发现从产品原型到设计稿再到页面实现，虽然有设计规范的约束，但三者之间还是会有差异，那么存在这个差异的核心原因是什么呢？

要实现前端物料及设计物料，需要设计者(产品经理、设计师)和开发者使用的是同一份物料，那么就有两种方式：本地设计和在线设计；

本地设计就是要让设计者在 sketch 上能够使用前端物料来设计页面，这里我们通过 react-sketch 这个库实现了在 sketch 上渲染 react 组件，从而实现让设计者在 sketch 上使用前端物料来设计页面；

而在线设计是我们正在探索的新思路，这也是低代码搭建的一个很好的应用场景。我们可以想一下，产品经理产出原型稿是不是在相应的工具(例如 axure)上进行“搭建”，设计师产出设计稿是不是也是在设计工具(sketch)上进行“搭建”，而使用低代码研发平台的开发者也是在搭建平台通过前端物料进行页面产出；那么既然三者都是搭建，那是否可以使用同一套搭建体系呢？设计在线就是这个思路，我们站着设计者的视角提供搭建工具，在不增加设计者原先工作量的前提下，然设计者能够更快速的产出高保真原型，并且这个原型可以直接流转到低代码研发平台让开发者进行二次搭建。

关于本文 作者：@金禅 原文：http://june.cool/blog/kk06ev

为你推荐

欢迎自荐投稿，前端早读课等你来。