lml frontend

@mrmlnc Does this issue still being tracked?

Hopefully this issue will be taken seriously again

加上`getContainer`方法可以暂时解决该问题，但是如果页面有多个table就不行了 ``` getContainer = (instance) => { console.log('instance', instance) return document.querySelector('.virtuallist') } DraggableContainer = (props) => ( ); ```

目前我是采用设key的方式暂时解决，但还是希望官方能有系统解决方案。 

1. 渲染器不应该被入料组件绑定具体前端框架，理想情况下应该是入料之后将源码组件转化成协议描述 2. 渲染器应该支持cdn方式，起码应该是es 3. 增强数据源功能。现在的数据源更像是http配置器，但更贴合低代码这个词的话，我理解应该分两部分： - 给用户定义和组件相关的数据结构。如select组件需要`{label: string, value: string}[]`结构数据，form需要单个对象。 - 底层配置真正从后台获取数据的部分，可能有restful风格请求、静态文件请求、mock数据等 最后将两部分结合，形成能真正给组件传数据的工具。 按这样的想法，数据源应该是一个完整概念，包含相关的插件、setter，让用户在使用的时候只专注在自己组件需要什么数据。 4. 增强setter功能。现在setter的返回值直接就是搭建协议的一部分，但我认为在返回值和搭建协议之间应该还有一层转化。因为可能在体验上setter让用户配了很多东西，最后输出可能只是一条表达式，问题就出在再次打开setter时可能很难从表达式返回到之前配置的样子。 注：我知道底层提供了transducer的能力，但是在我看来这更像是个“补救措施”，首先这个能力是同步的，可能实际场景是需要异步。第二我觉得这个所谓转化层应该由setter决定，这可能涉及到setter相关协议了。 5. 希望在实现上考虑非cdn。因为其实可以将低代码引擎用在electron或其他客户端开发上，客户端的重要场景之一就是离线，太多网络请求会集大增加客户端开发难度。之前也看过不少阿里相关文档将到为什么使用cdn这一方式，我也认同，但私心上还是希望能将这个需求考虑上。 6. 支持在画布双击组件编辑内容 7. 引用同步修改，类似vscode的f2 我自认为对阿里低代码理解得还比较深，对引擎源码也看过很多遍，但可能水平没达到阿里众位大佬的高度，希望以上内容能有所帮助。

> @proclml 关于渲染器被入料组件绑定具体框架的情况，现阶段的情况是入料组件基于某一个前端框架实现，且现在的前端框架基本上有一套自己的渲染实现，出于性能或者整体性的考虑会更偏向于整体应用使用同一个前端框架去渲染。 在理想情况下，低代码引擎可以拥有一套自己的全流程设施，但是那也需要付出非常大的改造代价，您有什么更好的建议么？ 我觉得可能两个思路。一个是我理解的您提到的全流程设施，代价可能会很大但其实是从根本上解决问题。另一个是能根据渲染器能根据入料组件决定如何渲染，简单理解就是vue2.6组件用vue2.6渲染器，vue2.7用vue2.7渲染器，react16.8用react16.8渲染器，相比第一种可能代价较小但维护难度反而更大。

另外，额外问个问题，协议里的`JSDataType`是什么？