低代码渲染那些事
作者:刘菊萍
一、低代码渲染是什么?
在了解低代码渲染之前,我们先来了解一下低代码渲染是什么?
首先,我们来考虑一下,低代码是什么?
比如下图的某低代码平台,都是通过可视化,即拖拽、配置,再加上很少的代码来设计出页面。
我们可以看到它的源码是一份 json 文件,这份 json 文件相当于是一份新的语言,浏览器是没有办法进行识别的,所以我们需要低代码渲染引擎将 json 渲染到浏览器中。
二、低代码如何渲染?
正如烹饪一样,为了成功做一份美食,我们需要菜谱和食材,然后通过不同的处理方式,比如煎、炒、炸等烹饪方式做出来一道菜。
我们的低代码渲染也是有类似的公式:
2.1 协议
其中菜谱我们可以认为这是一份标准,它保证了同样一道菜在不同地方 80%以上的口味都是一致的。如果缺少了这份标准,很有可能在不同的地方吃到的宫保鸡丁味道、食材等都完全不一样。
而低代码相关的协议就是低代码渲染的标准,如果低代码渲染都按照这一份标准来做,可以让不同部门、团队、公司低代码解析都是一致的。这样可以方便物料、工具集等生态产物进行无障碍流通。
协议也可以理解为是 React/Vue 等 ProCode 代码和低代码 json 源码如何互相解析的说明。
我们的协议有两份
《低代码引擎搭建协议规范》
《低代码引擎资产包协议规范》
这里我们对渲染所需的几个关键的协议字段做一下介绍。
协议原文:https://lowcode-engine.cn/lowcode
2.1.1《低代码引擎搭建协议规范》
componentsMap
它描述的是页面用到的组件的信息,例如从 ProCode 转化为我们的 json 协议内容如图:
destructuring 为 true 表示我们用解构的方式来获取组件。当然我们还有其他的描述字段来保证能支持各种组件的导出方式。
utils
它描述的是页面使用到的工具类扩展信息,比如我们页面中想使用 lodash.clone 方法,那么就需要在协议中这样描述:
componentsTree
componentsTree 描述的是页面的组件树,主要描述的内容相当于我们写的 JSX:
2.1.2《低代码引擎资产包协议规范》
搭建协议中虽然描述了组件的来源,但是我们在浏览器运行时无法使用 npm 引入,所以我们还需要资产包协议,来帮助我们获取组件、工具集等渲染所需材料。
packages
上图是 packages 的一个示例,它描述了一个组件的 urls,也就是我们需要加载上述的 urls。
加载之后,我们可以通过 window.Next.Button 获取到 Button 组件,如下图所示。
大家可以在https://lowcode-engine.cn/demo中尝试看看我们加载了多少组件。
2.2 材料
schema
我们在设计器中进行可视化拖拽、配置实际上就是为了产生我们的 schema。这份 schema 就是遵循《低代码引擎搭建协议规范》的产物,每一个页面对应一个 schema。
页面资产包
根据资产包协议规范,我们需要提供一份页面/应用的资产包信息。
在下图的某低代码平台里面,有一个依赖管理页面,在这里我们可以新增组件,在新增组件之后进行打包构建。
我们可以看到依赖配置信息中实际上是没有配置 urls 的,只是配置 package、version 等信息。
当我们点击打包构建时,我们会通过 package、version 等信息,将其打包成 UMD 资源,作为资产包中的 urls。
而这份 urls 会根据 package、version 进行存储并缓存,所以当我们新发布了一份 npm 包,并且进行打包构建的时候,打包构建的时间会比较长,而在第二个项目里面再添加一次,就很快了,这就是因为有了缓存,大大减少了打包构建时间。
组件和工具扩展
我们通过搭建协议中 componentsMap 的描述信息,可以知道 Button 组件是在 @alifd/next 中。
而通过资产包协议的 package 信息,我们就可以知道如何获取到 @alifd/next 内容,也就知道 Button 组件如何获取了。
通过这种方式,我们就可以获取到页面的 components 和 utils。
其他
我们还需要根据我们使用的技术栈,在 html 中提前加载 react/rax 相关依赖的资源。
如果是图表组件我们也需要加载 highcharts 资源。
当然还有更多的资源,可以根据情况进行引入。
2.3 渲染方式
渲染方式主要有两个大类:
出码渲染
运行时渲染
其中在阿里内部大多数低代码平台中,我们主要使用的都是运行时渲染,包括宜搭低代码产品,只有少部分对性能要求较高的产品才会使用出码渲染的方式。
出码渲染
出码渲染是将 schema 转化为 Vue 源码、React 源码或者其他语言的源码。当然就像 React 工程需要进行打包构建才能在浏览器中渲染一样,我们会将 React/其他源码进行打包,打包成一份 Bundle 文件,之后就可以在浏览器中进行消费,渲染出页面了。
以上的过程大多数都是在构建服务中进行的,而 Bundle 渲染为页面是在浏览器中完成的,这一部分本身都是依赖市面上成熟的前端框架,比如 React、Vue 等,所以这时候在浏览器的运行时已经不存在低代码渲染了。
下面是某个页面的 schema 转化为 React ProCode 的示例:
这里对出码渲染就不做过多的介绍了,有兴趣的小伙伴可以去看看低代码引擎中的出码模块。
运行时渲染
运行时渲染和出码渲染的主要区别在于,页面 schema 渲染成页面都是在浏览器中完成的,不存在预编译的过程。
三、运行时渲染详解
这里我们就运行时渲染进行详细的介绍。
3.1 渲染能力概览
渲染能力就是我们运行时渲染引擎根据协议需要支持的能力。
比如我们要渲染的一个页面,可以把它解析成一个树状结构,而其中的最底层的节点就是我们最小粒度的组件。
对于这个组件,我们需要支持的能力主要是:
1)获取源码组件
2)解析组件的 props
3)获取组件的 children
3)保留并传入上下文,包括循环上下文,插槽上下文等;
4)节点更新,当参数变化时需要更新对应的节点
5)节点循环处理
6)获取节点实例并进行存储
......
而比组件更大的一个纬度来说,也就是页面的渲染,而他们的能力需要:
1)页面生命周期的生成和执行;
2)页面内组件树描述生成,并递归处理单个组件;
3)页面上下文生成,比如数据源 State、低代码组件的 Props 等。
4)页面 API 支持;
......
3.2 组件渲染
3.2.1 获取源码组件
通过 Node 的 componentName 和之前获取到的 components 就可以获取到 React/Rax 的源码组件。上面的渲染所需材料获取的模块已经介绍过了。
3.2.2 解析 props
为了实现所有的搭建场景,我们的 props 有几种解析方式:
1、参数是确定的值
配置的值是确定的,比如确定的 text 文本。
2、参数是需要计算的表达式
配置的值根据数据源进行变化的,比如说 text 文件需要根据 state.text 进行计算的场景。
这里会用 type:JSExpression 来描述需要计算的表达式。
3、参数是函数
参数是作为函数传到组件中,比如说 Button 组件配置的 onClick 事件、onChange 事件等。
这里会用 type:JSFunction 来描述函数。
4、参数是 React/其他框架的节点
协议中还描述了某一种属性作为 ReactNode 渲染的情况,这时候组件渲染的内容不是 children,而是这个组件的某一个参数。
其中 type 为 JSSlot 就是描述这种情况的参数格式。
上面代码中的 Card 中的 this.props.title 在 React 渲染引擎下就会解析成 ReactNode。
3.2.3 获取组件的 children
通过递归处理即可获取其 children,下图是其伪代码。
3.2.4 处理节点更新机制
当数据源变化的时候,我们需要对页面进行更新,主要有两种更新方式,全量更新和增量更新。
全量更新
全量更新就是只要数据源发生变化,我们就从页面的顶层节点,也就是 Page 开始从头开始再次进行计算、递归子元素并对 props 进行计算。也就是每一个节点都会重新计算和渲染。
这样的好处的是处理比较简单,而坏处就是由于多了不必要的计算和渲染,在性能上较差,特别是如果节点比较多就会出现明显的卡顿。
增量更新
增量更新是找到用到这个数据源的组件才进行更新,也就是上图中的 TextA 和 TextC。
我们实现的方式就是利用了 mobx,如下图所示我们将 state 和 props 进行 observable。并对每一个组件都进行 observer 观测,当组件用到的 state 或者 props 产生变化的时候,mobx 会控制其进行更新。
3.2.5 处理节点循环
由于在循环的场景中,循环的组件和其子组件需要通过 this.item 和 this.index 来获取循环的索引和循环的值。
所以我们在节点循环的时候,我们需要计算循环的值,并将循环的值,作为当前节点和节点的 children 的 scope 来解析。
3.2.6 处理节点实例
当我们配置了组件的 ref,我们就可以通过 this.$(ref)来获取组件实例。
在 React 中,我们主要是直接利用组件的 ref 参数,来获取到组件的实例,并将其存储到渲染引擎的上下文中。
3.3 页面渲染
3.3.1 执行页面生命周期
在搭建协议中,定义的生命周期方法主要是 React16 的标准生命周期方法,对于 React 的渲染引擎来说,只需要在合适的时机调用相关生命周期方法即可。
而对于其他语言的渲染引擎,我们就需要根据情况,在其类似的生命周期中调用 schema 中的生命周期方法。比如 Rax 技术栈的渲染引擎,由于没有类似的生命周期,所以使用 hooks 来替代对应的生命周期;当然对于使用者来说是感知不到差别的。
3.3.2 递归解析组件树
下面是其递归组件树示例的一个伪代码。
而在递归之后,我们就可以按照组件的渲染逻辑,对单个组件进行渲染了。
递归处理组件
按照前文提到的组件渲染相关的逻辑对每一个组件进行处理。就可以按照组件树的层级关系将其绘制到浏览器上。
3.3.3 页面上下文生成
上下文、状态和数据管理和层级以及包裹的组件是有关系的,其中页面下的组件,使用的是页面的上下文、数据和状态。在页面包裹的区块下的组件,优先使用区块下的上下文、状态和数据,如果区块中不存在,这时会去页面上下文、状态和数据中寻找。
上下文、状态和数据管理使用的是 proto 来实现的。当进入区块时,会新建区块数据和区块上下文,并使用 proto 来继承页面上下文和页面数据,这样就可以在区块中优先使用区块的数据和上下文,当区块中没有的时候,会向页面数据和上下文中查找。整体逻辑类似下面的伪代码:
输出结果如下:
实现上述的几个逻辑,就可以完成一个最简单的运行时低代码渲染引擎了。
版权声明: 本文为 InfoQ 作者【阿里技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/1294efb60b1ae51a7aae092d5】。文章转载请联系作者。
评论