唐澜

有stylelint可以 > 在 2019年1月4日，下午6:29，SolerZhou 写道： > > scss-lint能输入标准的scss代码么 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view...

@mengying0608 两个页面指的是什么场景呢？ 设计器还是渲染之后的应用？

@736473283 原先的渲染器在实现的时候依赖了 next， 可以作为 external 引入

> 1、拖动节点时的性能问题 2、模拟器的重新加载功能 3、引擎拆开出大纲树插件 @1377023219 1、2 已记录，3得考虑引擎侧的设计了

> 来个共建机制把，一起搞吧。Q_Q 共建方式还在讨论中～。

> 渲染器期望支持 CDN。现在的 React-Render 只有 npm 包，相对于 CDN 的方式，升级对用户的影响更大。 @liujuping 资源产物也计划提供 umd 和 esm 的形式呢 1. npm 包的形式提供给二开或者希望自己构建的用户 2. 资源产物的形式对于开箱即用的用户更加友好 所以我期望的是都会提供

> 提几个我们遇到的常见feature > > 1. 源码面板支持高阶语法，比如 script type module的默认支持（现在已知扩展符、async/await 等不太友好） > 2. 源码面板支持接入 ai 暴露一些hook 函数等 > > 不好解的问题： > > 1. 表单或表格等性能，选中的时候子项多的时候比较卡 > 2. 菜单树多的时候也比较卡 @jiangtao 源码面板的能力可以通过自定义面板插件和出码插件实现的。卡顿性能的问题的确也是这次重写的关键原因之一。

> 1. 迫切需要自由画布支持，以实现BI大屏类的功能，能够自定义画布尺寸，并在渲染时以大屏方式全屏适应。 > 2. 组件联动目前需要自定义事件通知，虽然可以实现，但代码量大且代码味道不是太好。 > 3. 个人认为之前的代码实现不太清晰，组件之间的耦合度过大，虽然引擎拆分了组件，但之间的依赖太强，有一些功能扩展过于依赖fork，包括引擎初始化和加载组件，总有点感觉味道怪怪的，我也说不清楚，仅供参考。 > 4. 上面有人提到了性能问题，个人感觉目前的性能不够好，有些情况下非常卡顿，建议这方面的标准再提升一下。 > 5. 引擎中内置的样式和主题的样式，对项目样式有污染，经常出现进入设计器或渲染之后项目的样式发生改变，同时也希望样式可以更好的定制化。 > 6. 之前有兄弟提到过内外网隔离的部署，next组件库的样式中有强引用cdn图片，造成网络隔离环境部署很困难。 > 7. 引擎相关配置还不够细致，可能是由于我不太熟悉，对于右侧属性布局的控制不够细致，应该对选项卡、变量等都可以实现控制。 > 8. 数据源支持扩展，目前支持的配置比较简单，希望提供更清晰的强大的定制化能力。 > 9. 属性窗口的希望变得更灵活比如宽度、浮动。 > 10. 完善debug日志，可以在遇到问题时更好的排查。...

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

> 1. 增加源码面板代码编译方案 > 2. 表单方案优化完善（中后台表单场景较多且复杂），我们接了formily的setter，使用体验不是很好，卡顿 bug也比较多 > 3. 多语言方案优化，目前需要再setter中绑定 i18n处理函数，交互不是很友好 > 4. 内部给予开源的vue3 render实现了vue2.7 render，后续看是否有共建的可能 vue renderer 的需求可以持续关注