简介： 低代码烘托是什么? 在了解低代码烘托之前，咱们先来了解一下低代码烘托是什么？ 首先，咱们来考虑一下，低代码是什么？ 比方下图阿里内部的某低代码渠道，阿里对外的低代码产品有宜搭。他们都是经过可视化，即拖拽、装备，再加上很少的代码来规划出页面。
咱们能够看到它的源码是一份 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 烘托成页面都是在浏览器中完结的，不存在预编译的进程。
运转时烘托详解
这儿咱们就运转时烘托进行详细的介绍。
烘托才能概览
烘托才能便是咱们依据协议的内容，在运转时烘托引擎上支撑的才能。
比方咱们要烘托的一个页面，能够把它解析成一个树状结构，而其间的最底层的节点便是咱们最小粒度的组件。
关于这个组件，咱们需求支撑的才能首要是：
-
获取源码组件
-
解析组件的 props
-
获取组件的 children
-
保留并传入上下文，包含循环上下文，插槽上下文等;
-
节点更新，当参数变化时需求更新对应的节点
-
节点循环处理
-
获取节点实例并进行存储
……
而比组件更大的一个纬度来说，也便是页面的烘托，而他们的才能需求：
-
页面生命周期的生成和履行；
-
页面内组件树描绘生成，并递归处理单个组件；
-
页面上下文生成，比方数据源 State、低代码组件的 Props 等。
-
页面 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 调试才能建设与实践》
未来规划
最后咱们的运转时烘托体系架构最终会完结成这样。
而在解决方案上会将一部分完善低代码调试才能、也会供给服务端烘托才能解决运转时烘托才能的性能瓶颈。
原文链接：click.aliyun.com/m/100034854…
本文为阿里云原创内容，未经答应不得转载。
