关于前端:基于-LowCodeEngine-的调试能力建设与实践

作者：刘菊萍 (絮黎)

概述

业务背景

低代码因为研发效力和交付的劣势变得越来越遍及，在降本提效的同时也带来了很多黑盒逻辑。现有的低代码平台广泛不足面向用户的调试能力，当用户在低代码搭建遇到问题时，排查和解决问题强依赖平台的客服答疑或浏览器原生的调试能力，导致非前端用户应用低代码平台的老本很高。因而咱们须要提供更适宜低代码平台的调试能力，升高低代码平台的应用老本。

技术难点

在阿里低代码引擎的产品技术体系中，一方面咱们须要提供低代码平台的根底调试能力，实用于大多数低代码的调试能力，须要思考非前端用户的应用习惯和学习老本；另一方面因为低代码平台的指标用户类型差别较大，不同低代码平台所需的调试能力也是不一样的，除了根底的调试能力之外，咱们须要通过提供扩大定制能力，帮忙不同的低代码平台疾速建设适宜的调试能力。

技术细节

在技术架构上，咱们通过分层设计，将调试体系分为 Client、Server、Protocol 等不同层来承当不同的职责，向下做好协定的对立收敛，与低代码引擎的协定和渲染体系对接，向上也能反对不同分层下的高度定制。在产品设计上，咱们在低代码引擎标准协议的根底上实现了日志查看、错误码定位、审查元素、数据源查看与批改等低代码调试能力上的摸索。具体实际和剖析：低代码引擎体系下的调试能力在团体内的中后盾平台 A 落地了半年，沉闷用户总量为 600，占比平台总月活的 20%，并大幅度降低了答疑中调试相干问题的占比。

低代码引擎介绍

低代码引擎是一款为低代码平台开发者提供的，具备弱小扩大能力的低代码研发框架。由阿里巴巴前端委员会、钉钉宜搭联结出品。使用者只须要基于低代码引擎便能够疾速定制合乎本人业务需要的低代码平台。同时，低代码引擎还在规范低代码设计器的根底上提供了简略易用的定制扩大能力，可能满足业务独特的性能须要。

开源地址： https://github.com/alibaba/lo…

官网： http://lowcode-engine.cn/#/

点击文末「浏览原文」，可间接跳转查看

低代码调试背景介绍

在阿里外部有很多低代码平台，其中图中的这款低代码平台是用于开发中后盾页面。因为这个平台积淀的工夫比拟久，因而用户量绝对比拟多，笼罩的人群类型也比拟宽泛。

该低代码平台月沉闷用户有大略 4000 人左右，这 4000 人外面有前端、后端、测试开发等。其中大略只有 30% 的使用者是前端研发，而剩下 70% 的使用者都是非前端研发人员。为了帮忙这 4000 人应用该低代码平台，该低代码平台提供了两个前端全职进行答疑，帮忙该平台的使用者解决他们遇到的问题。

咱们能够看到，答疑同学一个月大略须要解决 400 多个答疑工单，这些工单外面有大量的应用问题和利用调试问题。

那咱们来假如一下，如果这个低代码平台没有前端同学来进行答疑，那是不是有至多 400 多个使用者有可能无奈应用咱们的低代码平台。我认为是十分有可能的，在这种状况下，如果他们遇到问题，找不到渠道来解决问题的，因而对低代码平台产生不好的印象，他们就很容易摈弃掉这个低代码平台，甚至摈弃掉所有的的低代码平台也是有可能的。

这样咱们能够看进去这个低代码平台有两个问题：

• 答疑老本高 ，对于非前端研发同学来说，非常依赖答疑同学提供的反对，这样会导致低代码平台用户量越多，答疑老本就越高，
• 学习门槛高 ：就算有足够的答疑反对，非前端研发应用低代码平台也有较高的学习老本，这就导致低代码平台很难进行更大范畴的推广。

因而，咱们须要去缩小答疑的老本，为了找到缩小答疑的解决方案，咱们先来剖析一下答疑的案例。

这是一个答疑同学在答疑过程中和低代码平台的使用者沟通的过程。

在最开始的时候，用户会跟答疑人员说遇到了一个报错，须要答疑人员帮忙看看问题在哪里。这时候个别都须要用户提供能够让答疑人员复现问题的步骤。比如说，须要提供报错页面的地址。在大多数状况下，这些页面都有权限管控，须要找对应的权限管理员来增加权限。甚至有的我的项目因为增加权限太麻烦，只能通过截图或者视频来查看和定位问题。

所以这个案例裸露进去的第一个问题是权限管控会让答疑工夫更长，也让查看和定位问题的难度更高了。

咱们持续看第二局部，当权限增加实现之后，用户和答疑人员往往还要沟通复现门路，因为用户和答疑人员沟通过程往往存在信息差，所以须要重复沟通能力明确复现的步骤，答疑人员能力复现出报错场景，能力找到到问题。

咱们能够看进去，这里裸露的第二个问题是复现问题沟通耗时且繁琐。

找到问题之后，发现这些问题很有可能是一些对于前端很简略的问题，比如说标点符号应用谬误，中英文符号应用谬误等。因为大多数低代码平台的使用者是非前端开发，他们没有前端相干的根底。因而对于前端来说很简略的问题没有方法本人解决，就只能依赖答疑人员的帮忙。那如果短少了答疑，没有前端根底的使用者想要解决相似的问题，学习老本还是十分高的

因而，一方面为了缩小答疑的沟通老本、另外一方面为了升高非前端研发同学的学习老本。咱们决定为低代码平台提供低代码调试工具。

低代码调试能力建设

首先咱们来看一下该低代码平台调试的现状。这里咱们设计了一个页面，这个页面在设计器中是没有问题的，然而当咱们在某一个组件中配置了一个谬误的表达式，咱们在预览的时候就会看到页面呈现报错。对于前端来说，能够关上控制台查看报错信息，报错信息就像图中展现的这样。

这个报错信息能帮忙低代码开发师找到问题吗？实际上，不论是对于前端研发人员来说，还是对于非前端研发来说，都是很难间接定位到问题的。

一方面，这个页面很有可能有几百上千个节点，每一个节点都有很多个配置。这个报错信息没有通知咱们这个报错的代码是配置在哪个组件节点外面的。也不能让用户关上每一个节点来查看每一个配置。

另外一个方面，低代码平台能够配置代码的中央很多，这样就导致咱们的代码是十分散乱的。咱们无奈通过现有信息晓得报错代码配置的形式，配置的中央。也就是说，就算是前端，也很难找到报错代码的。

为了让低代码平台的使用者能本人解决这类调试问题，咱们就须要提供一个调试工具，让用户能够

• 直观的晓得如何查看报错的内容
• 能够依据报错内容，晓得报错的代码在哪里
• 在找到报错的代码之后，晓得如何去批改代码，修复问题。

有了这个工具之后，低代码平台的使用者就能够本人解决问题，也就大大减少对答疑人员的依赖了。

对于第一个问题，咱们须要让低代码平台的使用者晓得“如何查看报错”，咱们提供的解决方案是，在遇到报错的时候，咱们通过一个显眼的标识来通知用户，你开发的页面呈现谬误了，其中谬误的个数有多少个。用户看到这个标识之后，就会去点击这个标识。当用户点击之后，就会在页面中呈现低代码调试工具，来帮忙用户查看报错相干的信息。

在这个调试工具中，咱们通过展现日志的形式，来让用户更加直观的找到跟谬误无关的信息。并且，缓缓的用户就晓得咱们提供了一个工具来帮忙他们开发低代码页面。之后遇到其余问题也会本人关上低代码调试工具，相当于起到了锤炼用户开发习惯的作用。

在用户晓得如何查看报错之后，接下来的问题就是如何通过日志输入的能力，让用户晓得谬误的代码在哪里。

对于这个问题，咱们通过给不同类型的报错提供对应的错误码，来帮忙用户找到报错代码。

1. 首先对于不同类型的谬误，咱们会提供一个独自的错误码，并且还会提供对应的上下文信息，比方组件 ID 是多少，用户配置的表达式内容是什么；
2. 当然有了这些信息还是不够的，咱们还须要将上下文信息用更语义化的形式展现给用户。因而为了更好的组织这些错误码、对应的上下文信息以及展现给用户的形容文案，咱们利用错误码治理后盾来治理这些信息。

有了这些信息，咱们在低代码调试工具的日志面板中就能够展现出十分具体的信息来帮忙用户找到报错的代码。

比方：之前咱们在控制台中看到的谬误，在日志面板中展现的内容就变成了：某某某组件表达式执行呈现谬误，并给出了谬误的起因，给出了谬误的表达式内容，谬误的组件 ID 等信息。用户通过组件 ID 就能够在低代码平台中进行搜寻，就能够找到对应的组件了。也就能找到报错的代码了。

对于非前端研发来说，咱们帮忙用户找到谬误的代码还不能齐全解决问题，咱们还须要通知他们如何批改代码来解决谬误。

为了解决这个问题，咱们在谬误日志的根底上，减少了一个外链性能，用户能够点击这个外链，关上一个错误码对应的文档，这个文档通过图文的形式具体的形容了问题的解决步骤。这样对于一些简略的问题，用户就能够找到解决方案。

当然，对于一些绝对简单的报错案例，用户可能还是无奈本人解决问题，还是须要答疑人员的帮忙。为了缩小用户和答疑人员来回沟通的老本，咱们还反对用户上传页面日志，日志中会携带页面的要害信息，比如说日志内容、搭建产生的 JSON 源码，环境信息等等。这样就能够缩小工单解决的时长。

第二个用户会遇到的问题是？对于大多数低代码产品，他们的在页面设计时所看到的成果，和理论预览的时候看到的成果在一些状况下是不统一的。比如说咱们在设计这个页面的时候，给某个组件配置了表达式，而这些表达式在画布中是不会进行计算的。这样会导致一个问题。设计时看到的成果和理论展现看到的成果是不统一的。

比方这里的按钮展现的就不一样。那么当咱们在预览的时候，如果成果和咱们的冀望的不一样，咱们就想晓得

• 这个组件的配置表达式是什么？
• 这个组件展现的文案是怎么计算出来的？

之前为了解决这些问题，用户须要回到设计器中，找到对应的组件，查看这个组件的配置能力解决。而对于一些简单的配置，比方三元表达式，用户为了找到问题，还须要在很多中央增加 Console，查看数据源的值。因而为了帮忙用户疾速的定位到单个组件配置的问题，咱们提供了组件审查性能。

它的成果是这样的，当切换到组件审查面板的时候，用户能够点击页面中的元素，或者点击纲要树中对应的组件，就能够看到这个组件的详细信息。

比方这里有一个低代码开发的页面，咱们须要查看页面中某一个按钮的展现逻辑。

1. 咱们就能够点击这个按钮，就能够看到这个组件的详细信息
2. 首先展现的详细信息，是这个组件依据配置计算出来的值，咱们能够看到这个按钮展现的文案起源是 content 这个参数的值。
3. 第二个展现的信息是这个组件配置的原始内容，这里咱们就能够看到 content 这个参数值实际上配置的是一个表达式，也就是 content 的值是依据 state.text 的表达式计算来的。
4. 第三个咱们展现的信息是这个组件能够拜访到的上下文信息，比方 this.state 的值是多少，比方 this.utils 下有哪些函数等等。

这样用户就能够通过这个工具，一步步查看组件参数的配置，也能够推导出它的计算过程，如果不合乎预期也能够疾速的发现并晓得如何解决问题。

除了刚刚提到的这两个工具之外，咱们还提供了数据源面板和 schema 面板两个调试工具。

• 数据源面板： 数据源面板能够让用户查看页面数据源的值，并且为了不便低代码平台的用户对数据源进行调试，数据源面板还反对批改数据源的值。
• schema 面板 ：对于低代码平台来说，所有的可视化操作和配置，实际上操作的都是一个 json 对象，这个 json 对象咱们把它叫做 schema，咱们也提供了 schema 面板来查看页面渲染时应用的 schema 源码。

以上就是咱们针对该低代码平台建设的低代码调试能力。然而它只能解决一个低代码平台的问题，为了帮忙更多的低代码平台解决相似的问题，咱们还须要提供低代码调试扩大能力。

低代码调试扩大能力

在阿里，将近有 200 多个低代码平台，而刚刚咱们提到的低代码平台只是这外面中的一个。那么其余低代码平台须要调试能力吗？必定也是须要的，不过他们须要的不只是咱们之前提到的调试能力，他们还须要依据本人平台的特点，来定制适宜本人平台的调试能力。

比方，

• 有的平台的用户是前端，就冀望能通过浏览器插件来进行调试，这样更合乎前端用户开发调试的习惯；
• 而有的平台，提供的是表单搭建能力，比如说宜搭。就更须要表单相干的调试性能；
• 有的平台就想在调试能力上加一个按钮，来帮忙用户找到答疑入口。

为了满足不同低代码平台对调试能力的诉求，咱们须要在低代码调试能力的根底上提供扩大能力，让低代码平台能够定制对应的调试能力。

• 插件化： 首先咱们须要将调试能力进行插件化，插件化的意思是将每一个调试能力都形象为一个插件。这样能够不便不同的低代码平台抉择不同的调试能力，并且能够对调试能力进行插拔，平台须要什么调试能力就能够援用对应的插件。
• 根底调试能力 ：在将调试能力插件化之后，咱们就能够将之前建设的调试能力作为根底调试能力，并且积淀成根底调试能力插件，比方日志调试能力插件、元素审查调试能力插件等等。
• 调试扩大能力 ：当根底调试能力不满足低代码平台的诉求时，低代码平台就须要利用咱们提供的调试扩大能力，来开发自定义调试插件。
• 低代码平台开发者 ：当咱们有了根底调试能力和调试扩大能力之后，低代码平台的开发者就能够基于这两个能力开发平台的调试能力了。

首先低代码平台开发者能够看看现有的根底调试能力是否适宜本人的低代码平台，并且抉择适宜本人低代码平台的根底调试能力。

根底调试能力无奈满足的局部，低代码平台就须要开发对应的调试能力插件。自定义调试插件开发实现之后，就能够和根底调试能力组合到一起。这样，低代码平台就领有了更适宜本人平台的调试能力。

比方：

• 低代码平台 A，就抉择了元素审查的根底调试能力，并且基于本人平台的搭建特点，开发了表单调试能力。
• 低代码平台 B，就抉择的是日志的根底调试能力，并开发了图表调试能力。

这样不同的低代码平台就能够领有更适宜本人平台的调试能力，这个就是咱们最终冀望实现的低代码调试扩大能力，

接下来的问题是：咱们要如何实现低代码调试扩大能力，并且它还能用于几十、上百个低代码平台。

侥幸的是，在咱们建设低代码调试扩大能力之前，阿里团体大部分低代码平台都是基于低代码引擎来建设的。也就是阿里外部 200 个低代码平台中，有将近 130 个低代码平台是基于低代码引擎来实现低代码搭建和渲染的。

有了这个前提，咱们就能够站在伟人的肩膀上，通过给低代码引擎这个体系提供规范的低代码调试能力，以及低代码调试扩大能力，来服务越来越多的低代码平台。

正如咱们之前提到的，大多数低代码平台，可视化拖拽和配置实际上都是在操作一份 json 文件。低代码引擎也不例外，并且低代码引擎还对这个 json 文件制订了一份标准协议，也就是「低代码引擎搭建协定」。因而通过低代码引擎建设的低代码平台，在可视化操作之后，都会产生一份合乎搭建协定的 json schema。

这份 json schema 浏览器是无奈间接进行解析渲染的，因而还须要依靠于「渲染引擎」来解析 schema，将低代码页面绘制到浏览器中。那么这个渲染引擎是不是只有一套呢？并不是。因为渲染引擎在绘制页面的时候，还会用到大量的根底组件或者业务组件，这些组件用到的技术栈可能是不一样的，为了让不同技术栈的物料都能渲染到浏览器中，渲染引擎也须要依据不同的技术栈实现多套。

因而，咱们有多套渲染引擎。例如 React 渲染引擎、Rax 渲染引擎、以及将来还会有 Vue 渲染引擎等。

介绍了那么多对于渲染引擎的信息，那渲染引擎和调试能力是什么关系呢？

调试能力须要通过渲染引擎能力获取到页面信息。为什么这么说呢，咱们先看一下低代码页面绘制的过程。

1. 首先低代码平台通过可视化配置，会产生一份形容页面的 json schema。
2. 在页面渲染的时候，渲染引擎会依据 schema 的内容绘制页面，并且除了 json schema 之外，渲染引擎还须要晓得，json schema 中形容的组件和插件是什么样的。所以也须要把整个页面会用到的组件、第三方插件等信息给到渲染引擎。
3. 渲染引擎有了这些信息之后，才会在浏览器上绘制进去页面。

在整个绘制过程中，浏览器晓得 schema 的内容吗？以及晓得每一个组件的参数值吗？实际上，浏览器是不晓得的，因为这些执行和解析的过程都是由渲染引擎实现的。那么调试能力须要晓得这些信息，就只能通过渲染引擎来获取。

• 比如说须要通过渲染引擎来获取页面的 schema
• 比如说须要跟渲染引擎来获取单个组件的参数值。

因而调试能力须要通过某种形式和渲染引擎进行通信，比方通过 API 来进行通信。然而正如之前咱们提到的，渲染引擎依据不同的技术栈实现了多套，而每一套渲染引擎提供的 API 都有可能是不统一的。因而咱们不能基于渲染引擎的 API 来开发调试能力。

这里为什么说不能呢？设想一下，如果有这样一个低代码平台，它即反对 PC 页面的搭建也反对 H5 页面的搭建，然而 PC 页面应用的可能是 React 版本的渲染引擎，而 H5 页面应用的是 Rax 版本的渲染引擎。那么同样的调试能力就须要依据两个不同版本的渲染引擎 API 来做兼容，或者说可能须要开发两套。这必定是不合理的，那调试能力和渲染引擎之间就须要一个沟通的规范。

这个通信的规范就是低代码调试协定。它通过定义渲染引擎和低代码调试能力之间通信的规范，来抹平不同版本渲染引擎在 API 和实现上的差别。比方：

• 它定义了渲染引擎如何被动告诉调试能力；
• 它也定义了调试能力如何被动通过渲染引擎获取到相干的信息。

这样的益处是，

• 对于低代码平台的开发者来说，他们在开发低代码调试能力的时候能够不必关注页面用的是什么技术栈的渲染引擎。也不须要做任何兼容和适配的工作；
• 对于低代码引擎来说，不同技术栈得渲染引擎在实现了低代码调试协定之后，就能够反对所有曾经开发好的调试能力。

接下来让咱们看看调试协定是如何进行定义的。

首先在定义协定之前，咱们再来明确一下咱们定义协定的目标是什么。它的次要的目标还是用来实现调试能力的开发。而调试能力开发须要的次要分为两个方面：

1.schema 获取和操作类型

第一个是 schema 的获取或者批改相干的操作。比方获取整个页面的 schema，获取单个组件节点的参数和状态。这些操作实质上都是在获取或者操作 schema。

基于低代码引擎建设的低代码平台，产生的 schema 是依据低代码引擎搭建协定标准生成的。因而咱们操作 schema 就是操作搭建协定形容的构造。为了让调试能力更不便的操作搭建协定，咱们将搭建协定分成了三层。

• 第一层是搭建协定的顶层构造，为了操作这一层构造，咱们在调试协定中定义了 schema 调试域。这样就能够通过 schema 调试域来获取整个页面的 json schema 或者说批改整个页面的 json schema。
• 第二层是搭建协定中的容器构造，容器是一类非凡的组件，在组件能力根底上还减少了一些非凡能力，比如说它有独自的自定义办法和数据源。因而咱们定义了 Container 调试域来操作容器这一层构造。这样咱们就能够在调试能力中批改容器的数据源或者调用容器中的自定义办法了。
• 第三层就是搭建协定中的单个组件构造，在调试中必定须要对单个组件进行操作，比如说须要晓得组件计算后的参数值，组件的原始配置，获取组件的 json schema 等等。因而咱们定义了 Node 调试域来操作这一层构造。

2. 辅助类型

除了获取或者批改 schema 相干的操作之外，在调试的时候，咱们还须要一些辅助类型的操作。比如说，调试能力想关上一个新的浏览器页面，就须要在浏览器窗口中执行对应的表达式。这些须要执行的表达式咱们就用 Runtime 这个调试域来进行通信。比方，当咱们审查元素的时候，须要页面呈现遮罩，来标识用户正在查看的组件是哪个。因而咱们定义了 Overlay 调试域来进行相干通信。

这样咱们的低代码调试协定就定义好了。接下来咱们看一下依据低代码调试协定，咱们实际上在调试过程中调试工具和渲染引擎通信的示例。

辅助类型 – Runtime 调试域

第一个例子，是一个辅助类型的域，也就是 Runtime 调试域。当调试能力冀望在新的浏览器窗口中关上一个新的页面时，就会发送一个 Runtime 域的 JSON，这个 JSON 中的 expression 字段就是定义了须要执行的表达式。当渲染引擎接管到这个 JSON 之后，通过解析，就晓得了它的用意，就会执行 JSON 中的表达式，执行实现之后，也会发送一个 JSON 告诉调试面板表达式执行实现。

schema 操作类型 – Schema 调试域

第二个例子，是对于操作低代码引擎搭建协定顶层构造的域，也就是 Schema 域，当 Schema 变动的时候，渲染引擎就会发送图中的 JSON 给到调试工具，调试面板就能晓得以后页面的 Schema 变动了，页面渲染的内容也就变动了，调试能力就须要执行相干的操作，比方更新 schema 调试面板展现的内容，更新审查面板的纲要树等等。

低代码调试协定目前基本上介绍的差不多了，咱们再思考一个问题，之前咱们提到这个协定由渲染引擎来发送，然而这样是不是适合呢？实际上是不适合的，因为对于低代码平台来说，线上环境和开发环境中用的渲染引擎都是同一个，在线上环境有那么多冗余的代码是有问题的。另外这种实现计划也会让渲染引擎有较大的改变，同时也会让应用旧版本渲染引擎的页面无奈应用调试能力。

那么由谁来发送调试协定呢，以及它又通过什么形式来和渲染引擎进行通信呢？

为了解决这个问题，咱们新增了一个代理人的角色，这样：渲染引擎告诉调试能力的形式就变成了，渲染引擎通过事件让代理人晓得要发送调试协定了，代理人就发送对应的调试协定。调试工具想获取 schema 的内容就变成了，调试工具发送的调试协定，由代理人来接管，接管之后代理人就会调用渲染引擎的 API 来获取 schema 的内容。失去后果之后代理人再将后果通过调试协定发送给低代码调试工具。

减少代理人的益处是：

• 渲染引擎只须要提供相干的 API，而不须要为了调试能力进行大规模的改变。
• 代理人只有在开发低代码平台页面时才存在，这样就不会影响到咱们的线上环境。

咱们看一下理论通信的例子，

1. 首先在页面初始化的时候，代理人会调用渲染引擎的 API，来注册日志回调事件，相当于跟渲染引擎说，有日志了记得告诉我；
2. 当渲染引擎呈现日志的时候，就会调用代理人注册的回调函数，相当于告诉代理人，有日志了，日志内容是某某某。
3. 代理人收到告诉之后，就会发送对应的调试协定，也就是图中的 Json 对象。
4. 低代码调试能力就会接管到对应的协定，也就能够执行相干的操作，这里就是将接管到的新日志展现进去。

咱们曾经定义好了低代码调试协定，也实现了渲染引擎和调试能力之间的通信能力。

接下来咱们还须要提供一个容器来展现根底插件和自定义插件。

依据展现的类型，咱们将插件分为两种：

1. Tab 类型 ：比方之前的日志面板。对应图中的黄色区域。
2. Action 类型 ：当点击的时候，它只会执行一些操作，比方上传日志，比方跳转到答疑页面等等。这些插件会展现在图中的红色区域。

用户能够依据本人须要的调试能力来抉择开发不同类型的插件。

咱们当初基本上曾经实现根本的调试扩大能力了，为了让低代码平台能够更便捷的开发低代码平台调试能力，咱们还提供了调试相干研发的工具链，让用户能够初始化开发插件，调试插件以及整合插件。除了工具链之外，咱们还提供了更不便的 API 来操作调试协定，这样用户开发调试能力的时候就不必写 JSON 了。

这样咱们的低代码调试扩大能力就建设实现了。

低代码调试能力实际

在阿里的这款中后盾低代码平台中，应用调试能力的月沉闷用户有 300 人，平台的答疑量升高了 10% 左右。

其中一些简略的答疑基本上曾经隐没了，比如说因为跨域，一些接口申请会呈现谬误，之前也有很多同学因为这类问题找到咱们答疑同学，当初之类答疑曾经没有了，并且因为组件表达式配置谬误，而导致的页面报错，这种类型的答疑也少了很多。

此外，阿里对外的商业化低代码平台，钉钉宜搭，因为大多数搭建场景是在搭建表单页面，他们也依据表单页面的特点，扩大了对应的调试能力。能够反对查看表单数据和谬误申请。

目前低代码调试能力还处于刚刚萌芽的阶段，还须要一直摸索和建设。就像浏览器提供给前端研发丰盛的调试能力一样，低代码畛域将来还会有十分丰盛的调试能力，这些调试能力能够帮忙越来越多的低代码开发师解决低代码搭建过程中遇到的问题。

下一步咱们还会建设更多的根底调试能力：

• 比方用户在低代码中写的 JS 代码，咱们能够在调试工具中查看和调试对应的 JS 代码。而不是须要回到设计器中能力查看。
• 比方能够在调试工具中查看页面的数据源申请信息。
• 比方能够查看页面或者容器生命周期的执行等等。

此外，咱们还会提供更多的低代码调试容器：

• 比方 Web 容器，适宜提供给非前端研发同学来应用。
• 比方浏览器插件容器，适宜提供给前端研发来应用，更适宜前端研发同学的调试习惯。
• 比如说客户端调试容器，提供给一些非凡调试场景来应用，比方用于挪动端调试场景。

最初，咱们也须要让更多的渲染引擎反对低代码调试能力，比方咱们低代码引擎中不同技术栈的渲染引擎，React 版本的渲染引擎和 Rax 版本的渲染引擎，以及将来由社区反对的 Vue 渲染引擎。