【RFC】关于低代码引擎渲染器2.0版本的计划及相关讨论
Opened this issue · 51 comments
大家好！
我们非常高兴地宣布，随着12月的临近，低代码引擎渲染器 2.0 的开发计划已经正式启动。我们的目标是提供一个更加强大且用户友好的低代码渲染解决方案。
在项目启动之前，我们对内外部用户进行了一次初步的调研，并对现有问题进行了整理。我们也非常欢迎大家对这些问题提出自己的意见和建议。
主要关注点：
-
代码架构改进:
- 实施更合理的分层设计策略。
- 支持多种视图库，如 React 和 Vue，同时计划淘汰对 rax 版本渲染器的支持。
-
能力的增强:
- 提升对不同场景的渲染能力，特别是应用级渲染和多端适配。
- 扩展用户端的能力，包括插件和生命周期管理。
- 引入支持最新技术特性，如更新版的 React 和 react-hooks。
-
性能的优化:
- 在复杂页面中优化容器状态流。
- 提高 eval code 字符串的执行效率。
-
用户体验的提升:
- 完善文档，涵盖使用入门、调试等方面。
- 加强配套设施。
我们的目标是在解决上述问题的同时，提供更友好的扩展能力，并为社区成员提供更多的实现空间。
特别地，应用级别的渲染能力是我们的优先考虑。因此，我们在 低代码搭建协议 中增加了一些关于路由协议的内容，详见条款2.11和2.12。
我们期待您的进一步想法和建议，欢迎在此 issue 下留言交流。
1、拖动节点时的性能问题
2、模拟器的重新加载功能
3、引擎拆开出大纲树插件
新的建议↓
4、不再局限this.utils.xxx，支持this.xxx的定义
1、拖动节点时的性能问题 2、模拟器的重新加载功能 3、引擎拆开出大纲树插件
1、3 是设计态的问题 👀。其中第三个主要是涉及到 breaking change，所以暂时没有拆分。
来个共建机制把，一起搞吧。Q_Q
渲染器期望支持 CDN。现在的 React-Render 只有 npm 包，相对于 CDN 的方式，升级对用户的影响更大。
1、拖动节点时的性能问题 2、模拟器的重新加载功能 3、引擎拆开出大纲树插件
@1377023219 1、2 已记录，3得考虑引擎侧的设计了
来个共建机制把，一起搞吧。Q_Q
共建方式还在讨论中～。
渲染器期望支持 CDN。现在的 React-Render 只有 npm 包，相对于 CDN 的方式，升级对用户的影响更大。
@liujuping 资源产物也计划提供 umd 和 esm 的形式呢
- npm 包的形式提供给二开或者希望自己构建的用户
- 资源产物的形式对于开箱即用的用户更加友好
所以我期望的是都会提供
提几个我们遇到的常见feature
- 源码面板支持高阶语法，比如 script type module的默认支持（现在已知扩展符、async/await 等不太友好）
- 源码面板支持接入 ai 暴露一些hook 函数等
- React JS 面板支持 hooks 写法
不好解的问题：
- 表单或表格等性能，选中的时候子项多的时候比较卡
- 菜单树多的时候也比较卡
- 每次保存代码后Redo、Undo不重置
- 数据源支持FormData，文件上传要使用
- 将目前的 monaco editor 改为 CDN 加载方式
- Render 支持服务端渲染
- 迫切需要自由画布支持，以实现BI大屏类的功能，能够自定义画布尺寸，并在渲染时以大屏方式全屏适应。
- 组件联动目前需要自定义事件通知，虽然可以实现，但代码量大且代码味道不是太好。
- 个人认为之前的代码实现不太清晰，组件之间的耦合度过大，虽然引擎拆分了组件，但之间的依赖太强，有一些功能扩展过于依赖fork，包括引擎初始化和加载组件，总有点感觉味道怪怪的，我也说不清楚，仅供参考。
- 上面有人提到了性能问题，个人感觉目前的性能不够好，有些情况下非常卡顿，建议这方面的标准再提升一下。
- 引擎中内置的样式和主题的样式，对项目样式有污染，经常出现进入设计器或渲染之后项目的样式发生改变，同时也希望样式可以更好的定制化。
- 之前有兄弟提到过内外网隔离的部署，next组件库的样式中有强引用cdn图片，造成网络隔离环境部署很困难。
- 引擎相关配置还不够细致，可能是由于我不太熟悉，对于右侧属性布局的控制不够细致，应该对选项卡、变量等都可以实现控制。
- 数据源支持扩展，目前支持的配置比较简单，希望提供更清晰的强大的定制化能力。
- 属性窗口的希望变得更灵活比如宽度、浮动。
- 完善debug日志，可以在遇到问题时更好的排查。
- 适配高版本react，解决一些控制台输出的一些异常。
- 想说一下组件库，引擎对组件的支持是很值得肯定的，强大的扩展能力非常爽，但还是感觉组件库的生态不够，个人认为如果没有能力扩展组件用低代码根本就解决不了实际问题，虽然官方提供了几套组件库的实现，但场景都很有限，开源虽然可以完善，但有没有感觉到大家很难去分享对其它人有用的组件库，我觉得这个问题应该想办法解决一下，我个人也想贡献，但总感觉无从下手，最后变成了我只为了满足我自己的项目而已。如何能够发动开源的力量，让大家把社区建设的更强大，光靠阿里的同志们是不够的。
- 不知道阿里的团队有没有掌握大家用引擎都做了什么，都为自己解决了什么问题，做了什么项目或产品，我是想了解的，我觉得阿里应该提供一个空间让大家更好的交流。
以上说的并不全面也不够准确，有一些问题应该是本人对引擎理解的不够造成的，但我相信可能很多朋友会有类似的感受，仅供参考。
提几个我们遇到的常见feature
- 源码面板支持高阶语法，比如 script type module的默认支持（现在已知扩展符、async/await 等不太友好）
- 源码面板支持接入 ai 暴露一些hook 函数等
不好解的问题：
- 表单或表格等性能，选中的时候子项多的时候比较卡
- 菜单树多的时候也比较卡
@jiangtao 源码面板的能力可以通过自定义面板插件和出码插件实现的。卡顿性能的问题的确也是这次重写的关键原因之一。
- 迫切需要自由画布支持，以实现BI大屏类的功能，能够自定义画布尺寸，并在渲染时以大屏方式全屏适应。
- 组件联动目前需要自定义事件通知，虽然可以实现，但代码量大且代码味道不是太好。
- 个人认为之前的代码实现不太清晰，组件之间的耦合度过大，虽然引擎拆分了组件，但之间的依赖太强，有一些功能扩展过于依赖fork，包括引擎初始化和加载组件，总有点感觉味道怪怪的，我也说不清楚，仅供参考。
- 上面有人提到了性能问题，个人感觉目前的性能不够好，有些情况下非常卡顿，建议这方面的标准再提升一下。
- 引擎中内置的样式和主题的样式，对项目样式有污染，经常出现进入设计器或渲染之后项目的样式发生改变，同时也希望样式可以更好的定制化。
- 之前有兄弟提到过内外网隔离的部署，next组件库的样式中有强引用cdn图片，造成网络隔离环境部署很困难。
- 引擎相关配置还不够细致，可能是由于我不太熟悉，对于右侧属性布局的控制不够细致，应该对选项卡、变量等都可以实现控制。
- 数据源支持扩展，目前支持的配置比较简单，希望提供更清晰的强大的定制化能力。
- 属性窗口的希望变得更灵活比如宽度、浮动。
- 完善debug日志，可以在遇到问题时更好的排查。
- 适配高版本react，解决一些控制台输出的一些异常。
- 想说一下组件库，引擎对组件的支持是很值得肯定的，强大的扩展能力非常爽，但还是感觉组件库的生态不够，个人认为如果没有能力扩展组件用低代码根本就解决不了实际问题，虽然官方提供了几套组件库的实现，但场景都很有限，开源虽然可以完善，但有没有感觉到大家很难去分享对其它人有用的组件库，我觉得这个问题应该想办法解决一下，我个人也想贡献，但总感觉无从下手，最后变成了我只为了满足我自己的项目而已。如何能够发动开源的力量，让大家把社区建设的更强大，光靠阿里的同志们是不够的。
- 不知道阿里的团队有没有掌握大家用引擎都做了什么，都为自己解决了什么问题，做了什么项目或产品，我是想了解的，我觉得阿里应该提供一个空间让大家更好的交流。
以上说的并不全面也不够准确，有一些问题应该是本人对引擎理解的不够造成的，但我相信可能很多朋友会有类似的感受，仅供参考。
@zxlaole 感谢提供宝贵的意见。
- 迫切需要自由画布支持，以实现BI大屏类的功能，能够自定义画布尺寸，并在渲染时以大屏方式全屏适应。
- 组件联动目前需要自定义事件通知，虽然可以实现，但代码量大且代码味道不是太好。
- 个人认为之前的代码实现不太清晰，组件之间的耦合度过大，虽然引擎拆分了组件，但之间的依赖太强，有一些功能扩展过于依赖fork，包括引擎初始化和加载组件，总有点感觉味道怪怪的，我也说不清楚，仅供参考。
- 上面有人提到了性能问题，个人感觉目前的性能不够好，有些情况下非常卡顿，建议这方面的标准再提升一下。
- 引擎中内置的样式和主题的样式，对项目样式有污染，经常出现进入设计器或渲染之后项目的样式发生改变，同时也希望样式可以更好的定制化。
- 之前有兄弟提到过内外网隔离的部署，next组件库的样式中有强引用cdn图片，造成网络隔离环境部署很困难。
- 引擎相关配置还不够细致，可能是由于我不太熟悉，对于右侧属性布局的控制不够细致，应该对选项卡、变量等都可以实现控制。
- 数据源支持扩展，目前支持的配置比较简单，希望提供更清晰的强大的定制化能力。
- 属性窗口的希望变得更灵活比如宽度、浮动。
- 完善debug日志，可以在遇到问题时更好的排查。
- 适配高版本react，解决一些控制台输出的一些异常。
- 想说一下组件库，引擎对组件的支持是很值得肯定的，强大的扩展能力非常爽，但还是感觉组件库的生态不够，个人认为如果没有能力扩展组件用低代码根本就解决不了实际问题，虽然官方提供了几套组件库的实现，但场景都很有限，开源虽然可以完善，但有没有感觉到大家很难去分享对其它人有用的组件库，我觉得这个问题应该想办法解决一下，我个人也想贡献，但总感觉无从下手，最后变成了我只为了满足我自己的项目而已。如何能够发动开源的力量，让大家把社区建设的更强大，光靠阿里的同志们是不够的。
- 不知道阿里的团队有没有掌握大家用引擎都做了什么，都为自己解决了什么问题，做了什么项目或产品，我是想了解的，我觉得阿里应该提供一个空间让大家更好的交流。
以上说的并不全面也不够准确，有一些问题应该是本人对引擎理解的不够造成的，但我相信可能很多朋友会有类似的感受，仅供参考。
我是 fusion 开发负责同学，fusion 相关的问题，可以来 fusion 提 issue，合理的我们都会快速支持。
- 渲染器不应该被入料组件绑定具体前端框架，理想情况下应该是入料之后将源码组件转化成协议描述
- 渲染器应该支持cdn方式，起码应该是es
- 增强数据源功能。现在的数据源更像是http配置器，但更贴合低代码这个词的话，我理解应该分两部分：
- 给用户定义和组件相关的数据结构。如select组件需要
{label: string, value: string}[]结构数据，form需要单个对象。 - 底层配置真正从后台获取数据的部分，可能有restful风格请求、静态文件请求、mock数据等
最后将两部分结合，形成能真正给组件传数据的工具。
按这样的想法，数据源应该是一个完整概念，包含相关的插件、setter，让用户在使用的时候只专注在自己组件需要什么数据。
- 增强setter功能。现在setter的返回值直接就是搭建协议的一部分，但我认为在返回值和搭建协议之间应该还有一层转化。因为可能在体验上setter让用户配了很多东西，最后输出可能只是一条表达式，问题就出在再次打开setter时可能很难从表达式返回到之前配置的样子。
注：我知道底层提供了transducer的能力，但是在我看来这更像是个“补救措施”，首先这个能力是同步的，可能实际场景是需要异步。第二我觉得这个所谓转化层应该由setter决定，这可能涉及到setter相关协议了。 - 希望在实现上考虑非cdn。因为其实可以将低代码引擎用在electron或其他客户端开发上，客户端的重要场景之一就是离线，太多网络请求会集大增加客户端开发难度。之前也看过不少阿里相关文档将到为什么使用cdn这一方式，我也认同，但私心上还是希望能将这个需求考虑上。
- 支持在画布双击组件编辑内容
- 引用同步修改，类似vscode的f2
我自认为对阿里低代码理解得还比较深，对引擎源码也看过很多遍，但可能水平没达到阿里众位大佬的高度，希望以上内容能有所帮助。
@proclml 关于渲染器被入料组件绑定具体框架的情况，现阶段的情况是入料组件基于某一个前端框架实现，且现在的前端框架基本上有一套自己的渲染实现，出于性能或者整体性的考虑会更偏向于整体应用使用同一个前端框架去渲染。
在理想情况下，低代码引擎可以拥有一套自己的全流程设施，但是那也需要付出非常大的改造代价，您有什么更好的建议么？
- 增加主题切换功能
- 自定义属性配置面板
- 优化schema配置大小问题，现在一个页面的schema配置有几十KB，大的100多KB了
- SelectSetter支持清除功能，目前选中值以后不能清空
- 增加源码面板代码编译方案
- 表单方案优化完善（中后台表单场景较多且复杂），我们接了formily的setter，使用体验不是很好，卡顿 bug也比较多
- 多语言方案优化，目前需要再setter中绑定 i18n处理函数，交互不是很友好
- 内部给予开源的vue3 render实现了vue2.7 render，后续看是否有共建的可能
- 增加源码面板代码编译方案
- 表单方案优化完善（中后台表单场景较多且复杂），我们接了formily的setter，使用体验不是很好，卡顿 bug也比较多
- 多语言方案优化，目前需要再setter中绑定 i18n处理函数，交互不是很友好
- 内部给予开源的vue3 render实现了vue2.7 render，后续看是否有共建的可能
vue renderer 的需求可以持续关注
希望改进点：
业务系统最重要的组件无非是 表单和 表格，希望重点优化放在这两个组件上：
1、表格类
希望增加，根据表格数据自动生成列的功能，因为复杂一点的业务系统，表格字段十几个甚至几十个，手动一个一个的添加，确实麻烦，如果可以根据表格的数据，如果可以根据数组对象的单个的对象 一键生成表格列，这样真是极大地方便使用者，使用者只需要微调列头名称，列的类型即可 ，这样酒极大的提升了效率
2、表单类（高级表格、筛序表单等）
也是希望增加一键对应字段的功能，比如拿到后台返回的 form表单的字段，里面有十几二十个字段要对应，现阶段也还是手动一个一个字段的对 上，确实有些麻烦，如果后期可以根据表单对象，一键把字段对应好，这样体验起来会事半功倍
希望官方能采纳我的提议，能实现上面的功能，真是极大的优化
其他的一些建议点：
1、目前引擎提供的自定义组件有点麻烦，希望可以增加一个组件，组件的功能就是自己写代码来实现自定义组件，然后直接可以把以前的代码直接拷贝进来 就可以使用，这样 体验会更好，相当于是在平台内的自定义组件功能
2、希望能平台增加几个钩子函数 ，方便使用者能在特殊节点前做特定的处理，现在想做一些特定处理找不到地方
3、再做变量绑定的时候，希望能做一些控制，比如我state中定义的对象，数据绑定的时候绑定了对象中的属性值，控制台会报错说是读取不到对象的属性值，这里是不是应该做一下控制，将对象的绑定时机放在能读取到的时候在执行
4、还有就是组件在使用接口数据的时候，如果接口返回数据慢，组件是不是能等到接口数据来了再渲染，而不是直接说读取不到数据，组件渲染失败，其实还是渲染时机没控制好的问题
以上我使用几个月的一些见解，希望官方可以考虑采纳，感谢开源项目，感谢阿里团队
@proclml 关于渲染器被入料组件绑定具体框架的情况，现阶段的情况是入料组件基于某一个前端框架实现，且现在的前端框架基本上有一套自己的渲染实现，出于性能或者整体性的考虑会更偏向于整体应用使用同一个前端框架去渲染。 在理想情况下，低代码引擎可以拥有一套自己的全流程设施，但是那也需要付出非常大的改造代价，您有什么更好的建议么？
我觉得可能两个思路。一个是我理解的您提到的全流程设施，代价可能会很大但其实是从根本上解决问题。另一个是能根据渲染器能根据入料组件决定如何渲染，简单理解就是vue2.6组件用vue2.6渲染器，vue2.7用vue2.7渲染器，react16.8用react16.8渲染器，相比第一种可能代价较小但维护难度反而更大。
特别开发自定义组件门槛太高了。希望 能在项目内就像自定义setter 一样就开发了。。另起一个项目各种bug各种问题 一堆。
1.希望增加区块组件支持预制方法和支持生命周期
2.应用开发时支持应用级别的css和function注入,便于抽象方法和css类
大家好！
我们非常高兴地宣布，随着12月的临近，低代码引擎渲染器 2.0 的开发计划已经正式启动。我们的目标是提供一个更加强大且用户友好的低代码渲染解决方案。
在项目启动之前，我们对内外部用户进行了一次初步的调研，并对现有问题进行了整理。我们也非常欢迎大家对这些问题提出自己的意见和建议。
主要关注点：
代码架构改进:
- 实施更合理的分层设计策略。
- 支持多种视图库，如 React 和 Vue，同时计划淘汰对 rax 版本渲染器的支持。
能力的增强:
- 提升对不同场景的渲染能力，特别是应用级渲染和多端适配。
- 扩展用户端的能力，包括插件和生命周期管理。
- 引入支持最新技术特性，如更新版的 React 和 react-hooks。
性能的优化:
- 在复杂页面中优化容器状态流。
- 提高 eval code 字符串的执行效率。
用户体验的提升:
- 完善文档，涵盖使用入门、调试等方面。
- 加强配套设施。
我们的目标是在解决上述问题的同时，提供更友好的扩展能力，并为社区成员提供更多的实现空间。
特别地，应用级别的渲染能力是我们的优先考虑。因此，我们在 低代码搭建协议 中增加了一些关于路由协议的内容，详见条款2.11和2.12。
我们期待您的进一步想法和建议，欢迎在此 issue 下留言交流。
结合我们内部已经实现的能力，有几个疑问：
- 协议升级兼容： 看有同学提到应用级css function 等注入，包含上面提到的应用级渲染，目前我们这边已经做了应用渲染、状态注入、utils、constants引入等，基本上是基于「低代码协议老版」做的扩展和存储。新版本的协议升级是否是 break 升级
- 多端适配： 多端适配是客户端跨端适配？
- 调试方面： 低代码在大量用户上车之后，二次迭代和维护成本相对来说比较高，比较好奇阿里内部是如何解决的。
- 入料成本： 同上面的同学提到的，目前调试物料因为有低代码平台之后，入料流程拉长（组件->低代码协议「setter等」-> 渲染呈现」）
1.更新更现代的构建工具 如现有build-script 0.1.32 是否有升级的可能 比如说使用vite?
2.现有 document 与 node 的概念能否统一 至少在使用层统一?
1.更新更现代的构建工具 如现有build-script 0.1.32 是否有升级的可能 比如说使用vite? 2.现有 document 与 node 的概念能否统一 至少在使用层统一?
- 第一点我们也在考虑
- @liujuping
1.更新更现代的构建工具 如现有build-script 0.1.32 是否有升级的可能 比如说使用vite? 2.现有 document 与 node 的概念能否统一 至少在使用层统一?
具体是哪些地方不统一呢？可以先列出来，我们后续看看能不能优化一下。
1.更新更现代的构建工具 如现有build-script 0.1.32 是否有升级的可能 比如说使用vite? 2.现有 document 与 node 的概念能否统一 至少在使用层统一?
具体是哪些地方不统一呢？可以先列出来，我们后续看看能不能优化一下。
- 文档模型: https://lowcode-engine.cn/site/docs/api/model/document-model
- 节点模型 https://lowcode-engine.cn/site/docs/api/model/node
例如文档模型拥有 insertNode 方法, onRemoveNode事件
节点模型有用 importSchema方法
到现在依然也存在一些困扰(如果不是我理解能力不足的话),这两个到底是什么关系,在什么情况下应该操作什么?
使用层统一我想表达的是在设计器内的一些操作,比如onRemoveNode事件,该方法目前也不完全稳定,比如某些场景删除了容器类的节点,而该节点内有子组件 该事件可能存在无法监听的情况(我不清楚内部实现,但理想中认为本事件应该内部实现递归触发,从而让事件订阅方知道删除了那些组件) 不清楚是bug 还是什么原因,亦或者不支持.
另一个例子,再次 importSchema之后,原文档事件似乎失效了,需要重新监听. 文档没写,也造成了一定的困扰.
首先非常开心官方开始了做渲染器 2.0 的开发，在日常使用中为了适配内部需求，也对渲染器做了一些定制：
- 路由 mock
- 增加了路由 mock 数据，方便获取路由参数等
- 监听路由跳转，匹配对应的低码页面做相应提示
- 为支持 SWR，给渲染器套了一层函数组件的 render props（看到官方渲染器 2.0 准备支持 hooks，表示非常开心）
下面是一些渲染器 2.0 的想法，仅供参考：
- 支持路由 mock，应用模拟器的话可以考虑支持下低码页面之间的跳转
- 支持解析 schema 中的 utils 和 constants，并实时生效
- 设置器能够比较方便的获取到模拟器的上下文，有时候需要在设置器中选择 utils 中的方法里暴露的一些属性，目前是通过特殊的方式拿到了模拟器上下文
- 低码组件支持增强
- 生命周期不执行，相关 issue：#1081
- 渲染器中低码组件的 context 是应用的 context，期望是低码组件自己的 context
- 对于已经在模拟器中渲染的低码组件，无法通过重新导入资产的方式更新低码组件为新的版本
- 期望 Component 组件可以把 ref 转发给低码组件，实际开发中在定制了 Component，使用 forwardRef 转发 ref，但是会有问题
- 期望有应用级别的低码组件，可以在应用编辑器中直接编辑低码组件，简化应用和低码组件的关联关系
- 大纲书插件
- 从渲染器中独立出来
- 提升性能以及 Modal 等弹出类组件的解析能力
- 对于条件渲染的节点也能够控制显示和隐藏
- 期望官方能提供一个好用的低码资产开发脚手架，更有利于低码组件资产的丰富，目前提供的 build-scripts 版本过于陈旧，实际开发中遇到了 esm 类型 package 不支持的问题，后面自己用 dumi 和 father 重新搭了一套低码资产开发方案： https://github.com/yuntijs/lowcode-materials
（先写这么多，后面想到了再补充）
期望后续能够参与到社区共建中，也希望低码引擎能够早日变成低代码世界的“水电煤”~
建议加入 大模型
首先非常开心官方开始了做渲染器 2.0 的开发，在日常使用中为了适配内部需求，也对渲染器做了一些定制：
- 路由 mock
- 增加了路由 mock 数据，方便获取路由参数等
- 监听路由跳转，匹配对应的低码页面做相应提示
- 为支持 SWR，给渲染器套了一层函数组件的 render props（看到官方渲染器 2.0 准备支持 hooks，表示非常开心）
下面是一些渲染器 2.0 的想法，仅供参考：
- 支持路由 mock，应用模拟器的话可以考虑支持下低码页面之间的跳转
- 支持解析 schema 中的 utils 和 constants，并实时生效
- 设置器能够比较方便的获取到模拟器的上下文，有时候需要在设置器中选择 utils 中的方法里暴露的一些属性，目前是通过特殊的方式拿到了模拟器上下文
- 低码组件支持增强
- 生命周期不执行，相关 issue：低代码业务组件中生命周期的写法 #1081
- 渲染器中低码组件的 context 是应用的 context，期望是低码组件自己的 context
- 对于已经在模拟器中渲染的低码组件，无法通过重新导入资产的方式更新低码组件为新的版本
- 期望 Component 组件可以把 ref 转发给低码组件，实际开发中在定制了 Component，使用 forwardRef 转发 ref，但是会有问题
- 期望有应用级别的低码组件，可以在应用编辑器中直接编辑低码组件，简化应用和低码组件的关联关系
- 大纲书插件
- 从渲染器中独立出来
- 提升性能以及 Modal 等弹出类组件的解析能力
- 对于条件渲染的节点也能够控制显示和隐藏
- 期望官方能提供一个好用的低码资产开发脚手架，更有利于低码组件资产的丰富，目前提供的 build-scripts 版本过于陈旧，实际开发中遇到了 esm 类型 package 不支持的问题，后面自己用 dumi 和 father 重新搭了一套低码资产开发方案： https://github.com/yuntijs/lowcode-materials
（先写这么多，后面想到了再补充）
期望后续能够参与到社区共建中，也希望低码引擎能够早日变成低代码世界的“水电煤”~
非常感谢提供的反馈，其中很多点也是我们希望优化的部分
希望可以切换画布模式。需支持自由布局画布，类似 https://excalidraw.com/ 这种，组件拖拽任意位置。
结合使用体验，提一点个人看法：
- 很多组件的行为是通过ref封装的，所以在生成组件meta时，希望可以把ref中封装的内容导出到meta信息中；
- 继第1项，在组件拖动到画布中之后就直接生成组件的refId而不是访问ref面板时再生成；
- 很多复杂业务逻辑除了尽可能封装到组件中之外，只能通过编写OriginCode去硬编码，说白了就是写一个React组件，只不过jsx渲染被画布代替了。一方面，在shema中生命周期，state状态，都要靠OriginCode解析生成，而实际上应该是OriginCode由预定义的生命周期和状态对象动态生成，现在的做法是本末倒置了，另一方面低代码平台的使用者可能并不擅长编码，尤其是还要了解React的机制。直接操作生命周期和状态对象更容易通过GUI实现，从而降低平台的使用门槛。
- 希望简化数据绑定的操作过程。举个例子：将一个Select(就称其为select1吧)选中的值作为一个数据源的请求参数，现在的做法是先在OriginCode的state中创建一个对象，和一个setState方法，然后将数据源的参数绑定到这个对象，将Select的onChange事件绑定到这个方法。参考其他低代码平台（如appsmith）只需将数据源的参数绑定到select1.value即可。这样省去很多步骤。
- 在运行时添加一个节点可访问/操作的状态容器，可以在页面间或应用-页面间传递动态数据。
- 开发组件库时发现构建工具build-script具有一定局限性。build-script更侧重于构建配置的复用和解耦，而在扩展性上有欠缺，配置项只能通过调查相应的插件才能获取，扩展性也几乎必须由插件提供，如果插件不满足要求就只能改写或者重写插件。另外就是还要同时查阅build-script和插件的文档。
- 增加数据源的定制能力，比如支持websocket。
以上仅是个人在平台日常开发使用过程中的一些感受，就是“如果能怎样怎样就好了”，谨供参考。
希望 渲染引擎 应该与具体前端框架无关， 使用vue,angular react 等都应该能使用使用。
结合使用体验，提一点个人看法：
- 很多组件的行为是通过ref封装的，所以在生成组件meta时，希望可以把ref中封装的内容导出到meta信息中；
- 继第1项，在组件拖动到画布中之后就直接生成组件的refId而不是访问ref面板时再生成；
- 很多复杂业务逻辑除了尽可能封装到组件中之外，只能通过编写OriginCode去硬编码，说白了就是写一个React组件，只不过jsx渲染被画布代替了。一方面，在shema中生命周期，state状态，都要靠OriginCode解析生成，而实际上应该是OriginCode由预定义的生命周期和状态对象动态生成，现在的做法是本末倒置了，另一方面低代码平台的使用者可能并不擅长编码，尤其是还要了解React的机制。直接操作生命周期和状态对象更容易通过GUI实现，从而降低平台的使用门槛。
- 希望简化数据绑定的操作过程。举个例子：将一个Select(就称其为select1吧)选中的值作为一个数据源的请求参数，现在的做法是先在OriginCode的state中创建一个对象，和一个setState方法，然后将数据源的参数绑定到这个对象，将Select的onChange事件绑定到这个方法。参考其他低代码平台（如appsmith）只需将数据源的参数绑定到select1.value即可。这样省去很多步骤。
- 在运行时添加一个节点可访问/操作的状态容器，可以在页面间或应用-页面间传递动态数据。
- 开发组件库时发现构建工具build-script具有一定局限性。build-script更侧重于构建配置的复用和解耦，而在扩展性上有欠缺，配置项只能通过调查相应的插件才能获取，扩展性也几乎必须由插件提供，如果插件不满足要求就只能改写或者重写插件。另外就是还要同时查阅build-script和插件的文档。
- 增加数据源的定制能力，比如支持websocket。
以上仅是个人在平台日常开发使用过程中的一些感受，就是“如果能怎样怎样就好了”，谨供参考。
@ppmmwozuiai 嗯嗯。里面有几点也是我们所希望的
2.0开发好了吗？
提一些小建议，希望官方可以考虑
- 代码编辑窗口是否可以通过插件同步到本地的 vscode 来打开进行实时编辑
- 是否可以考虑通过 gpt 的方式扫描一些预览图生成对应的组件模版，参考这个 https://github.com/abi/screenshot-to-code 可以生成前端代码
- 希望 setter 可以更解耦一些，现在比如 VariableSetter 其实实际的实现是在 MixedSetter 实现的，希望后面可以剥离的更清楚一些
2.0开发的怎么样了？支持vue3吗？
- 看到已经准备支持应用级应用，那是否可以支持和已有项目应用同步。比如低代码生成页面提交代码到github，github拉取也可以再低代码引擎中展示，双向通道。如果还是按照1.0中的出码功能，那后续应用级应用在进行procode的时候是要粘贴复制吗。希望这块有更好的体验！
希望支持react18，去年我们自己试着升级过，最后发现引擎中还是有一些不兼容的地方（比如说事件会响应两次），最后放弃了
请问2.0发布计划是怎么样，预计什么时候出内测版本。2.0版本是否和当前版本兼容？
- 全局化配置能否高度全屏，现在是拖动一个控件进去之后就变成控件的高度了，且想拖入全局化配置，需要在大纲树里操作
- 大纲树的拖动比较难用，精准插入某个空间中需要很仔细才能拖进去
- 弹窗与全局化配置不兼容，目前弹窗是特殊节点，直接挂在page下的，如果添加了ConfigProvider，只会和弹窗同级，不会影响到弹窗
2.0开发的怎么样了？期待公布预计开放时间及功能列表
- 组件渲染错误后仍可以选中
有时候由于配置错误导致组件渲染错误，无法选中就无法修改配置，不合理
没动静了呢
- 增加figma模板导入自动生成功能
- mobile和电脑尺寸布局样式可以不一样
- 加入nestjs router机制
- 数据库支持graphql
不会这个项目在内部挂了吧，还是被裁员了 没人接手了
期待啊，能不能加快点进度呢?
组件库 希望可以多支持一下移动端的
出码底层引擎支持三方小程序的出码，比如支付宝和微信小程序，可以通过插件的形式嵌入进来