background

Recently, the author has been using Taro to develop small programs for wechat. When introducing Echarts chart library, wechat has recorded a series of optimization measures for detecting single packet exceeding the limit of 2M, hoping to guide readers to take fewer detdettions.

Why Echarts?

The two most used chart libraries in the market are as follows:

  • Echarts-for-weixin — Echarts small program version of wechat
  • Wx-charts – Chart library based on wechat mini program

The advantages and disadvantages of the two chart libraries are opposite.

  • Echarts-for-weixin: Powerful, but very large
  • Wx-charts: Relatively simple function, but small size

Because the author is familiar with the use of Echarts, and wX-Charts does not support some of the functions that demand charts need to support, so the author finally chooses to use Echarts-for-Weixin, and the journey of stomping pits begins.

If a single packet exceeds 2 MB, what can I do?

The author introduced Echarts-for-Weixin, happy to finish the demand, ready to upload the code to release the micro channel small program experience version, pit began…

When a single packet exceeds the upper limit of 2 MB, the upload code is abnormal and the above pop-up message appears.

According to official requirements of wechat mini program, a single packet does not exceed 2M, and the whole packet does not exceed 16M

When a single packet exceeds 2M, the optimization scheme is as follows:

  • Load subpackages
  • Single package volume optimization (reduced code, compression, static resource CDN, etc.)

Since this development requirement belongs to a new function, the new function module is loaded by an independent subcontracted route. However, after subcontracting, the limit of single package still exceeds 2M.

After analysis, it is found that the Echarts components referenced by the business module will be packaged by Taro into the common.js module. As a result, all the subcontracted modules will double calculate the size of Echarts, resulting in the old subcontracted modules exceeding the limit of 2M.

Why is echarts-for-weixin packaged into the common.js module?

The reason is that Echarts is dependent on echarts-for-Weixin components and external business components, leading Taro to believe that echarts.js is dependent on multiple modules, so it is packaged into common.js.

To solve this problem, use splitChunks package configuration, package individual Echarts modules, and inject dependencies on the corresponding dependency page (addChunkPages) as follows:

// echartChunkName Output path of echarts mini: {webpackChain(chain) {chain.merge({optimization: {splitChunks: { cacheGroups: { [echartChunkName]: { name: echartChunkName, priority: 50. test(module) { return /subpackages[\\/]homeworkPage[\\/]studyData[\\/]ChartLine[\\/]ec-canvas[\\/]echarts.js/.test( module.resource ); },},},},},},}); }, addChunkPages(pages, pagesNames) { pages.set("subpackages/homeworkPage/studyData/ChartLine/index", [echartChunkName]); pages.set("subpackages/homeworkPage/studyData/ChartLine/ec-canvas/ec-canvas", [echartChunkName]); }}Copy the code

Taro customizes webpack configurations using mini. WebpackChain. For details, see the documentation on the official website

SplitChunks are subcontracted to webpack. Please refer to the documentation on the official website

Set subcontracting dependencies through mini-addChunkPages, please refer to the official website documentation

After the above treatment, common.js volume returns to normal, and that is the end of it.

As a result, new pits appear…… The diagram below:

Echarts-for-weixin component not found Echarts module dependency…

After a series of analysis, it was found that Taro has a problem with the dependency injection of splitChunks, a native wechat component, which has not been fixed yet.

You need to manually modify the compiled EC-Canvas. js to inject echarts dependencies after Taro compilation is successful, as shown below:

After the above processing, it finally runs normally, and the problem of single packet exceeding 2M has been solved.

Think this is the end of it?

I can’t manually modify the compiled file every time I compile it. If I forget to manually modify the compiled file, it will lead to online problems and high risk.

Therefore, you need to write an Taro package hack plug-in to automatically inject compiled Echarts dependency code.

It is easy to write the Taro plugin, please refer to the official documentation, the plugin code is as follows:

const fs = require('fs'); const path = require('path'); module.exports.default = module.exports = (ctx, Options) => {ctx.onBuildFinish(() => {console.log(' Echarts build hack injection ') const target = path.join(ctx.paths.outputPath, 'subpackages/homeworkPage/studyData/ChartLine/ec-canvas//ec-canvas.js'); const data = fs.readFileSync(target, 'utf8'); fs.writeFileSync(target, `require(".. /.. /echartCommon"); ${data}`) }) }Copy the code

Note: Custom plug-ins are supported only in Taro version 2.2 and later

The last

This is the end of Echarts’ record on the Development of Taro wechat applet. I hope you can help readers who are preparing to use the Echarts chart library in their application.