【RFC】关于低代码引擎渲染器2.0版本的计划及相关讨论

[1ncounter]

大家好！

我们非常高兴地宣布，随着12月的临近，低代码引擎渲染器 2.0 的开发计划已经正式启动。我们的目标是提供一个更加强大且用户友好的低代码渲染解决方案。

在项目启动之前，我们对内外部用户进行了一次初步的调研，并对现有问题进行了整理。我们也非常欢迎大家对这些问题提出自己的意见和建议。

主要关注点：

1. 代码架构改进:

   • 实施更合理的分层设计策略。
   • 支持多种视图库，如 React 和 Vue，同时计划淘汰对 rax 版本渲染器的支持。

2. 能力的增强:

   • 提升对不同场景的渲染能力，特别是应用级渲染和多端适配。
   • 扩展用户端的能力，包括插件和生命周期管理。
   • 引入支持最新技术特性，如更新版的 React 和 react-hooks。

3. 性能的优化:

   • 在复杂页面中优化容器状态流。
   • 提高 eval code 字符串的执行效率。

4. 用户体验的提升:

   • 完善文档，涵盖使用入门、调试等方面。
   • 加强配套设施。

我们的目标是在解决上述问题的同时，提供更友好的扩展能力，并为社区成员提供更多的实现空间。

特别地，应用级别的渲染能力是我们的优先考虑。因此，我们在 低代码搭建协议 中增加了一些关于路由协议的内容，详见条款2.11和2.12。

我们期待您的进一步想法和建议，欢迎在此 issue 下留言交流。

[hskww]

出码底层引擎支持三方小程序的出码，比如支付宝和微信小程序，可以通过插件的形式嵌入进来

[xiaofeihe]

@proclml 关于渲染器被入料组件绑定具体框架的情况，现阶段的情况是入料组件基于某一个前端框架实现，且现在的前端框架基本上有一套自己的渲染实现，出于性能或者整体性的考虑会更偏向于整体应用使用同一个前端框架去渲染。 在理想情况下，低代码引擎可以拥有一套自己的全流程设施，但是那也需要付出非常大的改造代价，您有什么更好的建议么？

amis 就不基于任何 前端框架， 这样 使用起来就 比较灵活了。

[xiaofeihe]

@proclml 关于渲染器被入料组件绑定具体框架的情况，现阶段的情况是入料组件基于某一个前端框架实现，且现在的前端框架基本上有一套自己的渲染实现，出于性能或者整体性的考虑会更偏向于整体应用使用同一个前端框架去渲染。 在理想情况下，低代码引擎可以拥有一套自己的全流程设施，但是那也需要付出非常大的改造代价，您有什么更好的建议么？

amis 就不基于任何 前端框架， 这样 使用起来就 比较灵活了。

[chenxlkamino]

啥时候发2.0啊

[milo-j]

还在继续吗

[chenxlkamino]

您的邮件已经收到，我会尽快给您回复-------陈孝亮 祝您生活愉快！

[xiaohuoni]

同求 figma