分享Echarts在太郎微信小程序开发中的踩踏记录(小程序使用echarts)

微信小程序开发教程专栏介绍了Echarts在Taro微信小程序开发中的踩踏记录。

背景最近作者正在用Taro开发微信小程序。在引入Echarts图表库时，微信检测了单包超过2M的一系列优化措施的踩踏记录，希望引导读者少走弯路。

为什么选择Echarts？微信小程序目录是市面上使用最多的两个图表库，如下:

Echarts-for-weixin——echarts微信小程序版本wx-charts——对比基于微信小程序的两个海图库的优劣，正好相反。

Echarts-for-weixin:功能强大，但是非常笨重wx-charts:功能相对简单，但是体积小。由于笔者对echarts的使用比较熟悉，而且有些需要需求图表支持的功能wx-图表不支持，所以最终选择使用echarts-for-weixin，踩坑之旅就此开始。

如果包裹超过2M，怎么处理？作者介绍了echarts-for-weixin，愉快的完成了需求，准备上传代码发布微信小程序体验版，坑就从这里开始了。...

当单个包超过2M上限时，上传代码异常，出现上面的弹出提示。

当单个包装超过2M时，有如下两种优化方案:

微信分包加载分包单包卷优化(减码、压缩、静态资源CDN等。)由于作者的开发需求属于新功能，新功能模块通过独立分包路线加载，但分包后仍有单个包超过2M的限制。

经过分析发现，业务模块引用的echarts组件会被Taro打包到common.js模块中，这将导致所有的分包模块重复计算echarts的大小，导致旧的分包模块超过2M限制。

为什么echarts-for-weixin被打包到common.js模块中？

原因是echarts依赖于echarts-for-weixin组件和外部业务组件，导致Taro认为echarts.js依赖于多个模块，所以打包到common.js中

为了解决这个问题，采用了splitChunks封装配置，将echarts的各个独立模块进行封装，然后将依赖注入到相应的依赖页面中。配置如下:

// echartChunkName echarts打包输出路径mini:{ webpackchain(chain){ chain . merge({优化:{拆分块:{cachegroups: {

echarts-for-weixin组件找不到echarts模块依赖项。...

经过一系列分析，发现Taro对splitChunks这个原生微信组件的依赖注入有问题。官方还没有修复这个问题。...

Taro编译成功后，手动修改编译后的ec-canvas.js，注入echarts依赖，如下图所示:

经过以上处理，最终运行正常，解决了2M上空单包的所有问题。

以为这样就结束了？每次编译后我都不能手动修改编译后的文件。如果我发的时候忘记手动修改版本，会导致上线问题，风险高。

所以需要编写一个Taro包hack插件来自动注入编译好的echarts依赖代码。

写Taro编译插件很简单，请参考官方文档。插件代码如下:

const fs = require( # 39；fs # 39);const path = require( # 39；路径 # 39；);module . exports . default = module . exports =(CTX，options)= gt；{ CTX . onbuildfinish(()= gt；{ console . log( # 39；Echarts构建黑客注入 # 39；)const target = path . join(CTX . paths . output path， # 39；subpackages/home work page/study data/chart line/ec-canvas//ec-canvas . js # 39；);const data = fs . read file sync(target， # 39；utf8 # 39);fs.writeFileSync(target，' require( ；../../echart common ；);$ {data} `)}}复制代码。最后，Echarts在Taro微信小程序开发方面的战绩即将结束。希望能给准备在Taro微信小程序中使用echarts海图库的读者一些帮助。

以上是分享Echarts在Taro微信小程序开发中跺脚记录的细节。请多关注主机参考其他相关文章！

这几篇文章你可能也喜欢：

• 暂无相关推荐文章

本文由主机参考刊发，转载请注明：分享Echarts在太郎微信小程序开发中的踩踏记录(小程序使用echarts) https://zhujicankao.com/81833.html