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
7条答案
按热度按时间zaqlnxep1#
Huawei OpenHarmony OS, please check https://ohpm.openharmony.cn/#/cn/home
ttp71kqs2#
除了发包到中心仓库,还有什么需要做的?有语法上面的改动吗?
x6yk4ghg3#
除了发包到中心仓库,还有什么需要做的?有语法上面的改动吗?
主要的工作量在
1: 如果依赖web 相关api, 需要适配成鸿蒙的api,这是工作量最大的部分
2: ts类型修改,鸿蒙的类型更加严格,可能需要进行一定程度的修改
3: 测试套件迁移到鸿蒙
发包基本没有工作量,和npm发布机制差不多。
现在是内部开发阶段,不便粘贴文档链接
我发起这个问题想确认两点
1:保留开源协议的情况下是否可以迁移(项目使用Apache License 2.0协议,所以是没问题的)
2: 框架方有没有迁移计划或者移动端定制版本可供迁移
ifmq2ha24#
框架方有没有迁移计划或者移动端定制版本可供迁移
我个人是支持 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
欢迎您帮助我们一起投入此项迁移适配工作~
vvppvyoh5#
框架方有没有迁移计划或者移动端定制版本可供迁移
我个人是支持 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,很多动态类型无法使用
测试上目前可能没办法
鸿蒙的版本和微信的版本有什么区别
鸿蒙的版本会有侵入式的修改,不同于微信版本直接使用构建好的文件。
导致这个的原因还是目标环境差异导致的
ruoxqz4g6#
目前的做法是 fork echarts项目,维护一个特定分支。在第一次适配完成后,主分支都同步上游仓库的更改,然后把这个分支合并到鸿蒙的分支。
大概目前只能这么做,就像 tengine 需要定期同步 nginx 的代码一样,不过这个可比 tengine 麻烦多了。😂
迁移zrender, 主要的工作量集中在适配dom api
可以先从 zrender 开始适配看看~
dldeef677#
目前的做法是 fork echarts项目,维护一个特定分支。在第一次适配完成后,主分支都同步上游仓库的更改,然后把这个分支合并到鸿蒙的分支。
大概目前只能这么做,就像 tengine 需要定期同步 nginx 的代码一样,不过这个可比 tengine 麻烦多了。😂
迁移zrender, 主要的工作量集中在适配dom api
可以先从 zrender 开始适配看看~
支持加载简单图形和动画
tianmuji/zrender@f8ac954
事件代理做了一部分,准备使用mitt事件总线代理来完成,但没完全完成
如果我司有迁移计划,会尝试迁移剩余部分,大概六月底会知道
或者如果你们有迁移计划 我愿意帮忙迁移一部分
目前鸿蒙的测试套件和语法还不完备,或许可以等等, 虽然鸿蒙那边表示会全力兼容web生态。