关于大厂使用iVX的一些问题反馈的回复！

[{"insert":"1.事件和数据驱动的部分必须要在点击编译按钮编译成功之后才能在新开的页面看到效果，且需要依赖网络环境，样式的效果直接设置值能看到大概效果，但也需要每次编译后才能查看最准确的，跟桌面端的idea实时更改在页面中直接看到效果相比体验还是有一定的差距。\n"},{"attributes":{"color":"#0070c0"},"insert":"【分三种情况：1. 修改之后马上显示的，多数都是CSS相关的；2. 预览显示，这个是用一个iVX虚拟引擎来运行了，不需要等编译时间，马上看到效果，但是运行效率相对比较低（基于WASM）；3. 编译之后，看最终运行效果，这个运行最快，但是需要编译时间。】"},{"insert":"\n \n2.生态还不太完善，很多组件尤其是PC端还比较缺少，仍在完善之中。对于一些功能的实现可能还需要想方设法去处理，不像原始的代码那样操作简便灵活。\n"},{"attributes":{"color":"#0070c0"},"insert":"【这个是对的，如果遇到新的问题，可能还需要一起去解决】"},{"insert":"\n \n3.自定义组件还在公测之中（基于2020-12-25)，如果有重复使用的内容只能复制过去再次进行更改，重复性工作较多\n"},{"attributes":{"color":"#0070c0"},"insert":"【研发说今天就合并上去：2021.1.4日】"},{"insert":"\n \n4.维护不太便捷，页面构造使用层层缩进的形式管理，如果项目工程较大，页面较多且定义的驱动数据很多时，层层递进的形式嵌套太深\n"},{"attributes":{"color":"#0070c0"},"insert":"【前后台已经拆分；项目可以拆分成多个应用；前端也可以拆分多人开发，例如，以页面为单位；后台以额可以拆分，例如以微服务为单位。不建议把一个大项目直接做在一个应用中。在我们的实际开发过程中都是这么处理的。感觉比较容易维护。】"},{"insert":"\n \n5.调试定位问题困难，如果想定位一个生产问题并且快速解决可能比较麻烦，因为对于开发者来说很多功能都是暗盒，没有暴露出来，相比现有构建的页面，调试更加不便\n"},{"attributes":{"color":"#0070c0"},"insert":"【前端调试，使用console log以及Chrome自带功能应该就够了，和现在前端调试过程比较类似；后台可以使用日志和服务接口。对于系统内部，应该都是透明的，每个功能都可以追溯。我觉得主要还是使用熟练问题。】"},{"insert":"\n \n6.如果页面想做后续的进一步加载的优化可能较难，只能依赖于ivx平台的各种特性\n"},{"attributes":{"color":"#0070c0"},"insert":"【常用的加载优化方式应该都有了，如果需要进一步优化，可以提出方案，我们集成进去。】"},{"insert":"\n \n7.操作繁琐，每新创建一个容器或者文本都要将所有的内容重新根据设计稿样式书写一遍，没有样式那般灵活\n"},{"attributes":{"color":"#0070c0"},"insert":"【正确的姿势是使用小模块，将所有需要重用的部分进行封装。】"},{"insert":"\n \n8.稍微深入使用需要查看很多视频和大量文档，社区暂不够完善，对于想要解决某个问题的方案可能难以找到现成的，官网论坛相对比较简洁，并且官网demo相对比较简单，pc端没有找到现成的完整功能的模板，需要自行构建\n"},{"attributes":{"color":"#0070c0"},"insert":"【我可以把论坛发给你们去研究，现成可用的模版，可能是不一定有，但是用iVX开发没有什么问题。】"},{"insert":"\n \n9.其他部分，稳定性待评估，从官方页面来看，如官方使用文档，仍有多余的构建目录文档，并且不是按需加载，首次加载资源比较庞大耗时，IE11下的表现也不是很好，使用过程中仍有各种小小的问题，如偶尔拖动卡顿等\n"},{"attributes":{"color":"#0070c0"},"insert":"【IE不是我们重点支持的引擎，11如果需要我们可以支持一下，可能在不断的开发过程中会累积IE的问题。研发较少关注IE。按需加载是按需的，但是每个开发工程师能力和关注也参差，这个和代码类似，多数为开发人员使用不当造成。】"},{"insert":"\n\n\n\n总的来讲，邓爷爷有一句名言“发展的问题只能通过发展来解决”，我们虽然开发iVX走到今天花了13年，但是iVX本身时间还很短（尽管在该领域绝对领先），所以无论是“文档”“教学”“各种资源”“生态” 都需要好好建设～ \n"}]

1.事件和数据驱动的部分必须要在点击编译按钮编译成功之后才能在新开的页面看到效果，且需要依赖网络环境，样式的效果直接设置值能看到大概效果，但也需要每次编译后才能查看最准确的，跟桌面端的idea实时更改在页面中直接看到效果相比体验还是有一定的差距。【分三种情况：1.修改之后马上显示的，多数都是CSS相关的；2.预览显示，这个是用一个iVX虚拟引擎来运行了，不需要等编译时间，马上看到效果，但是运行效率相对比较低（基于WASM）；3.编译之后，看最终运行效果，这个运行最快，但是需要编译时间。】 2.生态还不太完善，很多组件尤其是PC端还比较缺少，仍在完善之中。对于一些功能的实现可能还需要想方设法去处理，不像原始的代码那样操作简便灵活。【这个是对的，如果遇到新的问题，可能还需要一起去解决】 3.自定义组件还在公测之中（基于2020-12-25)，如果有重复使用的内容只能复制过去再次进行更改，重复性工作较多【研发说今天就合并上去：2021.1.4日】 4.维护不太便捷，页面构造使用层层缩进的形式管理，如果项目工程较大，页面较多且定义的驱动数据很多时，层层递进的形式嵌套太深【前后台已经拆分；项目可以拆分成多个应用；前端也可以拆分多人开发，例如，以页面为单位；后台以额可以拆分，例如以微服务为单位。不建议把一个大项目直接做在一个应用中。在我们的实际开发过程中都是这么处理的。感觉比较容易维护。】 5.调试定位问题困难，如果想定位一个生产问题并且快速解决可能比较麻烦，因为对于开发者来说很多功能都是暗盒，没有暴露出来，相比现有构建的页面，调试更加不便【前端调试，使用consolelog以及Chrome自带功能应该就够了，和现在前端调试过程比较类似；后台可以使用日志和服务接口。对于系统内部，应该都是透明的，每个功能都可以追溯。我觉得主要还是使用熟练问题。】 6.如果页面想做后续的进一步加载的优化可能较难，只能依赖于ivx平台的各种特性【常用的加载优化方式应该都有了，如果需要进一步优化，可以提出方案，我们集成进去。】 7.操作繁琐，每新创建一个容器或者文本都要将所有的内容重新根据设计稿样式书写一遍，没有样式那般灵活【正确的姿势是使用小模块，将所有需要重用的部分进行封装。】 8.稍微深入使用需要查看很多视频和大量文档，社区暂不够完善，对于想要解决某个问题的方案可能难以找到现成的，官网论坛相对比较简洁，并且官网demo相对比较简单，pc端没有找到现成的完整功能的模板，需要自行构建【我可以把论坛发给你们去研究，现成可用的模版，可能是不一定有，但是用iVX开发没有什么问题。】 9.其他部分，稳定性待评估，从官方页面来看，如官方使用文档，仍有多余的构建目录文档，并且不是按需加载，首次加载资源比较庞大耗时，IE11下的表现也不是很好，使用过程中仍有各种小小的问题，如偶尔拖动卡顿等【IE不是我们重点支持的引擎，11如果需要我们可以支持一下，可能在不断的开发过程中会累积IE的问题。研发较少关注IE。按需加载是按需的，但是每个开发工程师能力和关注也参差，这个和代码类似，多数为开发人员使用不当造成。】总的来讲，邓爷爷有一句名言“发展的问题只能通过发展来解决”，我们虽然开发iVX走到今天花了13年，但是iVX本身时间还很短（尽管在该领域绝对领先），所以无论是“文档”“教学”“各种资源”“生态”都需要好好建设～

关于大厂使用iVX的一些问题反馈的回复！1.事件和数据驱动的部分必须要在点击编译按钮编译成功之后才能在新开的页面看到效果，且需要依赖网络环境，样式的效果直接设置值能看到大概效果，但也需要每次编译后才能查看最准确的，跟桌面端的idea实时更改在页面中直接看到效果相比体验还是有一定的差距。【分三种情况：1.修改之后马上显示的，多数都是CSS相关的；2.预览显示，这个是用一个iVX虚拟引擎来运行了，不需要等编译时间，马上看到效果，但是运行效率相对比较低（基于WASM）；3.编译之后，看最终运行效果，这个运行最快，但是需要编译时间。】 2.生态还不太完善，很多组件尤其是PC端还比较缺少，仍在完善之中。对于一些功能的实现可能还需要想方设法去处理，不像原始的代码那样操作简便灵活。【这个是对的，如果遇到新的问题，可能还需要一起去解决】 3.自定义组件还在公测之中（基于2020-12-25)，如果有重复使用的内容只能复制过去再次进行更改，重复性工作较多【研发说今天就合并上去：2021.1.4日】 4.维护不太便捷，页面构造使用层层缩进的形式管理，如果项目工程较大，页面较多且定义的驱动数据很多时，层层递进的形式嵌套太深【前后台已经拆分；项目可以拆分成多个应用；前端也可以拆分多人开发，例如，以页面为单位；后台以额可以拆分，例如以微服务为单位。不建议把一个大项目直接做在一个应用中。在我们的实际开发过程中都是这么处理的。感觉比较容易维护。】 5.调试定位问题困难，如果想定位一个生产问题并且快速解决可能比较麻烦，因为对于开发者来说很多功能都是暗盒，没有暴露出来，相比现有构建的页面，调试更加不便【前端调试，使用consolelog以及Chrome自带功能应该就够了，和现在前端调试过程比较类似；后台可以使用日志和服务接口。对于系统内部，应该都是透明的，每个功能都可以追溯。我觉得主要还是使用熟练问题。】 6.如果页面想做后续的进一步加载的优化可能较难，只能依赖于ivx平台的各种特性【常用的加载优化方式应该都有了，如果需要进一步优化，可以提出方案，我们集成进去。】 7.操作繁琐，每新创建一个容器或者文本都要将所有的内容重新根据设计稿样式书写一遍，没有样式那般灵活【正确的姿势是使用小模块，将所有需要重用的部分进行封装。】 8.稍微深入使用需要查看很多视频和大量文档，社区暂不够完善，对于想要解决某个问题的方案可能难以找到现成的，官网论坛相对比较简洁，并且官网demo相对比较简单，pc端没有找到现成的完整功能的模板，需要自行构建【我可以把论坛发给你们去研究，现成可用的模版，可能是不一定有，但是用iVX开发没有什么问题。】 9.其他部分，稳定性待评估，从官方页面来看，如官方使用文档，仍有多余的构建目录文档，并且不是按需加载，首次加载资源比较庞大耗时，IE11下的表现也不是很好，使用过程中仍有各种小小的问题，如偶尔拖动卡顿等【IE不是我们重点支持的引擎，11如果需要我们可以支持一下，可能在不断的开发过程中会累积IE的问题。研发较少关注IE。按需加载是按需的，但是每个开发工程师能力和关注也参差，这个和代码类似，多数为开发人员使用不当造成。】总的来讲，邓爷爷有一句名言“发展的问题只能通过发展来解决”，我们虽然开发iVX走到今天花了13年，但是iVX本身时间还很短（尽管在该领域绝对领先），所以无论是“文档”“教学”“各种资源”“生态”都需要好好建设～