低代码渲染那些事

简介： 低代码烘托是什么? 在了解低代码烘托之前，咱们先来了解一下低代码烘托是什么？ 首先，咱们来考虑一下，低代码是什么？ 比方下图阿里内部的某低代码渠道，阿里对外的低代码产品有宜搭。他们都是经过可视化，即拖拽、装备，再加上很少的代码来规划出页面。

咱们能够看到它的源码是一份 json 文件，这份 json 文件相当于是一份新的言语，浏览器是没有办法进行识别的，所以咱们需求低代码烘托引擎将 json 烘托到浏览器中。

低代码怎么烘托?

正如烹饪相同，为了做成功一份美食，咱们需求菜谱和食材，然后经过不同的处理办法，比方煎、炒、炸等烹饪办法做出来一道菜。

咱们的低代码烘托也是有相似的公式：

其间菜谱咱们能够以为这是一份规范，它保证了同样一道菜在不同地方 80% 以上的口味都是一致的。假如缺少了这份规范，很有可能在不同的地方吃到的宫保鸡丁味道、食材等都完全不相同。

而低代码相关的协议便是低代码烘托的规范，假如低代码烘托都依照这一份规范来做，能够让不同部门、团队、公司低代码解析都是一致的。这样能够便利物料、东西集等生态产品进行无障碍流通。

协议也能够理解为是 React/Vue 等 ProCode 代码和低代码 json 源码怎么相互解析的阐明

咱们的协议有两份：

• 《低代码引擎建立协议规范》
• 《低代码引擎财物包协议规范》

这儿咱们对烘托所需的几个要害的协议字段做一下介绍。

协议原文：lowcode-engine.cn/lowcode

《低代码引擎建立协议规范》

componentsMap

它描绘的是页面用到的组件的信息，例如从 ProCode 转化为咱们的 json 协议内容如图：

destructuring 为 true 表示咱们用解构的办法来获取组件。当然咱们还有其他的描绘字段来保证能支撑各种组件的导出办法。

utils

它描绘的是页面运用到的东西类扩展信息，比方咱们页面中想运用 lodash.clone 办法，那么就需求在协议中这样描绘：

componentsTree

componentsTree 描绘的是页面的组件树，首要描绘的内容相当于咱们写的 JSX：

《低代码引擎财物包协议规范》

建立协议中虽然描绘了组件的来源，可是咱们在浏览器运转时中无法运用 npm 引入，所以咱们还需求财物包协议，来协助咱们获取组件、东西集等烘托所需资料。

packages

上图是 packages 的一个示例，它描绘了一个组件的 urls。当咱们烘托的时分，需求在浏览器中加载上述的 urls。

加载之后，咱们能够经过 window.Next.Button 获取到 Button 组件，如下图所示。

咱们能够在 lowcode-engine.cn/demo 中尝试看看咱们加载了多少组件。

资料

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 资源。

烘托办法

烘托办法首要有两个大类：

• 出码烘托
• 运转时烘托

其间在阿里内部大多数低代码渠道中，咱们首要运用的都是运转时烘托，包含宜搭低代码产品，只要少部分对性能要求较高的产品才会运用出码烘托的办法。

出码烘托是将 schema 转化为 Vue 源码、React 源码或许其他言语的源码。当然就像 React 工程需求进行打包构建才能在浏览器中烘托相同，咱们会将 React/其他源码进行打包，打包成一份 Bundle 文件，之后就能够在浏览器中进行消费，烘托出页面了。

以上的进程大多数都是在构建服务中进行的，而 Bundle 烘托为页面是在浏览器中完结的，这一部分本身都是依靠市面上成熟的前端结构，比方 React、Vue 等，所以这时分在浏览器的运转时已经不存在低代码烘托了。

下面是某个页面的 schema 转化为 React ProCode 的示例：

这儿对出码烘托就不做过多的介绍了，有爱好的小伙伴能够去看看低代码引擎中的出码模块。

运转时烘托

运转时烘托和出码烘托的首要差异在于，页面 schema 烘托成页面都是在浏览器中完结的，不存在预编译的进程。

运转时烘托详解

这儿咱们就运转时烘托进行详细的介绍。

烘托才能概览

烘托才能便是咱们依据协议的内容，在运转时烘托引擎上支撑的才能。

比方咱们要烘托的一个页面，能够把它解析成一个树状结构，而其间的最底层的节点便是咱们最小粒度的组件。

关于这个组件，咱们需求支撑的才能首要是：

1. 获取源码组件

2. 解析组件的 props

3. 获取组件的 children

4. 保留并传入上下文，包含循环上下文，插槽上下文等;

5. 节点更新，当参数变化时需求更新对应的节点

6. 节点循环处理

7. 获取节点实例并进行存储

……

而比组件更大的一个纬度来说，也便是页面的烘托，而他们的才能需求：

1. 页面生命周期的生成和履行；

2. 页面内组件树描绘生成，并递归处理单个组件；

3. 页面上下文生成，比方数据源 State、低代码组件的 Props 等。

4. 页面 API 支撑；

……

组件烘托

获取源码组件

经过 Node 的 componentName 和之前获取到的 components 就能够获取到 React/Rax 的源码组件。上面的烘托所需资料获取的模块已经介绍过了。

解析 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。

获取组件的 children

经过递归处理即可获取其 children，下图是其伪代码。

处理节点更新机制

当数据源变化的时分，咱们需求对页面进行更新，首要有两种更新办法，全量更新和增量更新。

1、全量更新

全量更新便是只要数据源发生变化，咱们就从页面的顶层节点，也便是 Page 开端从头开端再次进行核算、递归子元素并对 props 进行核算。也便是每一个节点都会重新核算和烘托。

这样的优点的是处理比较简略，而坏处便是因为多了不必要的核算和烘托，在性能上较差，特别是假如节点比较多就会呈现明显的卡顿。

2、增量更新

增量更新是找到用到这个数据源的组件才进行更新，也便是上图中的 TextA 和 TextC。

咱们完结的办法便是利用了 mobx，如下图所示咱们将 state 和 props 进行 observable。并对每一个组件都进行 observer 观测，当组件用到的 state 或许 props 发生变化的时分，mobx 会控制其进行更新。

处理节点循环

因为在循环的场景中，循环的组件和其子组件需求经过 this.item 和 this.index 来获取循环的索引和循环的值。

所以咱们在节点循环的时分，咱们需求核算循环的值，并将循环的值，作为当前节点和节点的 children 的 scope 来解析。

处理节点实例

当咱们装备了组件的 ref，咱们就能够经过 this.$(ref) 来获取组件实例。

在 React 中，咱们首要是直接利用组件的 ref 参数，来获取到组件的实例，并将其存储到烘托引擎的上下文中。

页面烘托

履行页面生命周期

在建立协议中，界说的生命周期办法首要是 React16 的规范生命周期办法，关于 React 的烘托引擎来说，只需求在合适的时机调用相关生命周期办法即可。

而关于其他言语的烘托引擎，咱们就需求依据状况，在其相似的生命周期中调用 schema 中的生命周期办法。比方 Rax 技术栈的烘托引擎，因为没有相似的生命周期，所以运用 hooks 来代替对应的生命周期；当然关于运用者来说是感知不到差别的。

递归解析组件树

下面是其递归组件树示例的一个伪代码。

而在递归之后，咱们就能够依照组件的烘托逻辑，对单个组件进行烘托了。

递归处理组件，依照前文提到的组件烘托相关的逻辑对每一个组件进行处理。就能够依照组件树的层级联系将其绘制到浏览器上。

页面上下文生成

上下文、状况和数据办理和层级以及包裹的组件是有联系的，其间页面下的组件，运用的是页面的上下文、数据和状况。在页面包裹的区块下的组件，优先运用区块下的上下文、状况和数据，假如区块中不存在，这时会去页面上下文、状况和数据中寻找。

上下文、状况和数据办理运用的是 proto 来完结的。当进入区块时，会新建区块数据和区块上下文，并运用 proto 来继承页面上下文和页面数据，这样就能够在区块中优先运用区块的数据和上下文，当区块中没有的时分，会向页面数据和上下文中查找。全体逻辑相似下面的伪代码：

输出结果如下：

完结上述的几个逻辑，就能够完结一个最简略的运转时低代码烘托引擎了。

目前我这边保护的运转时烘托结构首要有三套：

• lowcode-react-renderer 和 lowcode-rax-renderer ：是低代码引擎（lowcode-engine）供给的低代码运转时烘托才能，其底层运用的是 renderer-core。
• Render-Engine：是集团内部的根据 React 运转时的低代码烘托引擎，支撑使用等级的烘托，包含导航、登陆等使用等级的烘托才能。
• Rax-Engine：也是使用等级的烘托才能，运转时结构依靠的是 Rax。

痛点-保护本钱高

咱们的运转时烘托结构有独立的三套，而本身运转时的是有许多才能是通用的，是能够进一步基层复用，Renderer-Core 便是对通用的运转时烘托才能进行了基层，而 React 烘托器和 Rax 烘托器只需求针对差异部分进行适配。

解决方案

而三套独立的运转时烘托结构导致咱们的保护本钱是大于 3 的。根据这个原因，在后续的迭代中咱们会将通用才能基层，而他们之间的差异才能经过插件化来适配。

痛点-调试困难这个痛点是来自低代码渠道的运用者。

大多数看到这个问题的便是使用的开发人员，可是就算是开发人员，当遇到这个报错了也还是比较懵逼的，无从下手。这导致低代码渠道的答疑本钱一向比较高，而低代码运用者在运用低代码渠道的时分体验也会很差。

另外当遇到这个报错时，只要运用浏览器调试才能解决问题，这就导致了低代码研制人员有必要要有一部分的前端研制才能，导致低代码产品的运用人群无法进一步扩大。

解决方案

经过研制低代码烘托调试才能，来协助低代码渠道的运用着解决相关问题。相关解决方案即将在大会上进行线上直播分享，主题是《根据 LowCodeEngine 调试才能建设与实践》

未来规划

最后咱们的运转时烘托体系架构最终会完结成这样。

在低代码引擎规范协议的基础上，将运转时的通用逻辑进行下沉到 Renderer-Core 中，并根据它完结 React 烘托器和 Rax 烘托器。其他差异性的运转时烘托才能比方画布烘托、使用烘托等经过扩展插件来完结。

而在解决方案上会将一部分完善低代码调试才能、也会供给服务端烘托才能解决运转时烘托才能的性能瓶颈。

原文链接：click.aliyun.com/m/100034854…

本文为阿里云原创内容，未经答应不得转载。