echarts
echarts copied to clipboard
apache
[Question] Can echarts and zrender be migrated to HarmonyOS while keeping the license?
Version
5.0.0
Link to Minimal Reproduction
NOT AVA
Steps to Reproduce
I will keep the license in the final HarmonyOS version. But can I do that or do you guy have future plan to migrate
Current Behavior
Not bug issue
Expected Behavior
Not bug issue
Environment
- OS:
- Browser:
- Framework:
Any additional comments?
No response
除了发包到中心仓库，还有什么需要做的？有语法上面的改动吗？
主要的工作量在 1: 如果依赖web 相关api, 需要适配成鸿蒙的api，这是工作量最大的部分 2: ts类型修改，鸿蒙的类型更加严格，可能需要进行一定程度的修改 3: 测试套件迁移到鸿蒙
发包基本没有工作量，和npm发布机制差不多。 现在是内部开发阶段，不便粘贴文档链接
我发起这个问题想确认两点 1：保留开源协议的情况下是否可以迁移（项目使用Apache License 2.0协议，所以是没问题的） 2: 框架方有没有迁移计划或者移动端定制版本可供迁移
框架方有没有迁移计划或者移动端定制版本可供迁移
我个人是支持 ECharts 能兼容鸿蒙系统的，但考虑到目前维护人员情况，当前可能没有迁移计划。也无移动端定制版本。
主要的工作量在 1: 如果依赖web 相关api, 需要适配成鸿蒙的api，这是工作量最大的部分 2: ts类型修改，鸿蒙的类型更加严格，可能需要进行一定程度的修改 3: 测试套件迁移到鸿蒙
有较多代码层面上的改动的话，大概需要另开一个分支做专门适配（类似 echarts-for-weixin，但更为复杂），这应该需要投入较多时间和精力。
But can I do that or do you guy have future plan to migrate
欢迎您帮助我们一起投入此项迁移适配工作~
框架方有没有迁移计划或者移动端定制版本可供迁移
我个人是支持 ECharts 能兼容鸿蒙系统的，但考虑到目前维护人员情况，当前可能没有迁移计划。也无移动端定制版本。
主要的工作量在 1: 如果依赖web 相关api, 需要适配成鸿蒙的api，这是工作量最大的部分 2: ts类型修改，鸿蒙的类型更加严格，可能需要进行一定程度的修改 3: 测试套件迁移到鸿蒙
有较多代码层面上的改动的话，大概需要另开一个分支做专门适配（类似 echarts-for-weixin，但更为复杂），这应该需要投入较多时间和精力。
But can I do that or do you guy have future plan to migrate
欢迎您帮助我们一起投入此项迁移适配工作~
以下是我的想法和迁移计划
要不要迁移鸿蒙版本的echarts
目前主流的鸿蒙app都不具备可视化的能力，我认为这是一个机会
目前已经有的案例
我目前把fabric迁移到了鸿蒙，fabirc4HarmonyOS 目前还是beta版本
我打算怎么做
1: 迁移zrender, 主要的工作量集中在适配dom api
比如去除HTMLElement, 去除ssr模式等，这个会导致调用api接口参数发生变化 requestAnimationFrame可能需要去除，鸿蒙暂时不支持api，动画模块需要使用鸿蒙api实现 交互事件迁移，使用鸿蒙提供的交互接口而不是dom的点击事件
2: 迁移echarts，思路上和迁移zrender一样，但由于代码量大很多，工作量应该至少翻倍。
目前有的问题
如何持续集成，如何跟随echarts主版本发布鸿蒙版本？
目前的做法是 fork echarts项目，维护一个特定分支。在第一次适配完成后，主分支都同步上游仓库的更改，然后把这个分支合并到鸿蒙的分支。
如何测试鸿蒙版本的echarts?
如果使用ts文件，无法引入鸿蒙的测试套件 想使用必须修改成ets文件，这可能会要求修改大量类型代码，因为ets拓展了ts，很多动态类型无法使用 测试上目前可能没办法
鸿蒙的版本和微信的版本有什么区别
鸿蒙的版本会有侵入式的修改，不同于微信版本直接使用构建好的文件。 导致这个的原因还是目标环境差异导致的
目前的做法是 fork echarts项目，维护一个特定分支。在第一次适配完成后，主分支都同步上游仓库的更改，然后把这个分支合并到鸿蒙的分支。
大概目前只能这么做，就像 tengine 需要定期同步 nginx 的代码一样，不过这个可比 tengine 麻烦多了。😂
迁移zrender, 主要的工作量集中在适配dom api
可以先从 zrender 开始适配看看~
目前的做法是 fork echarts项目，维护一个特定分支。在第一次适配完成后，主分支都同步上游仓库的更改，然后把这个分支合并到鸿蒙的分支。
大概目前只能这么做，就像 tengine 需要定期同步 nginx 的代码一样，不过这个可比 tengine 麻烦多了。😂
迁移zrender, 主要的工作量集中在适配dom api
可以先从 zrender 开始适配看看~
支持加载简单图形和动画 https://github.com/tianmuji/zrender/commit/f8ac9544214f1ee936d1f4c894bd12f94578d76b
事件代理做了一部分，准备使用mitt事件总线代理来完成，但没完全完成
如果我司有迁移计划，会尝试迁移剩余部分，大概六月底会知道 或者如果你们有迁移计划 我愿意帮忙迁移一部分
目前鸿蒙的测试套件和语法还不完备，或许可以等等， 虽然鸿蒙那边表示会全力兼容web生态。