[Bug] echarts import map bug(empty canvas, but hover can see tips)

[CHENJIAMIAN]

Version

5.4.3

Link to Minimal Reproduction

https://codepen.io/571574085/pen/rNPXPZg

Steps to Reproduce

Open It, Wait Loaded. Hover Charts.

Current Behavior

https://codepen.io/571574085/pen/rNPXPZg

Expected Behavior

empty

Environment

No response

Any additional comments?

No response

[helgasoft]

not-a-bug Works as expected without three.js added - Demo Code

[CHENJIAMIAN]

Even after removing the code related to Three.js, the charts still don't appear.'

[helgasoft]

put all imported .js files in Settings, put your code in JS section Demo 📌 please close issue if problem solved

[CHENJIAMIAN]

put all imported .js files in Settings, put your code in JS section Demo 📌 please close issue if problem solved

Why does this solve the problem? I don't understand the principle behind it. Can you explain it to me?

[BerndAmend]

I have the same issue, I'm unable to get the example (https://echarts.apache.org/handbook/en/get-started/#) working if I use esm. (I only see the tooltip) import * as echarts from 'https://esm.run/echarts'; or https://cdn.jsdelivr.net/npm/[email protected]/dist/echarts.js It works fine if I use <script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/echarts.js"></script>

I think something is wrong with the esm files.

[JimmyAx]

Here is a minimal sample that will reproduce the bug. The canvas is empty but the tooltip shows up when hovered. ECharts must be imported using importmap for the bug to appear. Using a script tag to include it will work as expected. JSFiddle: https://jsfiddle.net/saltyprogrammer/ovLq8cd3/1/

For reference the HTML is also provided here, should it no longer reproduce in JSFiddle: echarts-importmap.html.txt

[JimmyAx]

Can still be reproduced with Apache ECharts 5.5.1.

[markbaydoun]

We are having the same bug in our frontend. I've tried downgrading echarts to 5.4.1 and vue-echarts to 6.6.9, because we recently updated the lockfile in the project and that's the only place where the change could have happened, but the bug still happens. The chart ends up rendering when the page is resized, so I think it's got something to do with how it detects changes and re-renders.

The only way we have been able to "fix" it is by rendering the chart only when a loading state is "false", and show a placeholder otherwise, but this is not ideal, as the loading state of the chart looks much better.

[vince83110]

Same error here, with Echarts 6.0.0, and using Symfony project with Importmap component, impossible to have it to work with ESM. Did anyone find a fix ?

For now, I use in my Stimulus JS Controllers:

import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  static targets = ["chart"];

  async connect() {
    const echarts = await import("https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.esm.min.js");
    const chart = echarts.init(this.chartTarget);
    const option = {
      xAxis: {
        type: 'category',
        data: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']
      },
      yAxis: {
        type: 'value'
      },
      series: [
        {
          data: [150, 230, 224, 218, 135, 147, 260],
          type: 'line'
        }
      ]
    };

    chart.setOption(option);
  }
}

And it works, but not a good solution

[romulocrj]

I had the same problem when updating my importmap to echarts version 6 at the URL indicated in jsdelivr: 'https://cdn.jsdelivr.net/npm/[email protected]/+esm'

However, reverting to the previous version, I realized I wasn't using the URL with the version, but rather the URL: 'https://cdn.jsdelivr.net/npm/echarts/dist/echarts.esm.js'. I believe this points to the latest version of eCharts. But the fact is, the chart works with this URL.

Searching this issue, I discovered that if you use the URL: 'https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.esm.js' or 'https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.esm.js' in the importmap, the chart works perfectly.

But I'm not sure if these are the correct versions.

Apparently there is a difference between the esm files in the jsdelivr URLs.