echarts: "Can't get dom width or height" incorrectly fires for width/height values of 0.

Version

4.2.1

Steps to reproduce

This warning from echarts: https://github.com/apache/incubator-echarts/blob/b6ab21159617b45c8077d998d468977cdd87d146/src/echarts.js#L1999 seems to be triggered when !dom.clientWidth, however I believe it is valid for dom.clientWidth to have a value of 0.

I’m not sure why this warning was added, but I think the check should be dom.clientWidth === undefined if the check is for a failure of the clientWidth API to exist.

What is expected?

warning should not occur for element width/height of 0

What is actually happening?

warning is logged.


I’m happy to resolve this issue, but I’d like some confirmation my hunch is correct, or a clarification for why it is not.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 8
  • Comments: 31 (2 by maintainers)

Commits related to this issue

Most upvoted comments

I’m seeing this during jest testing and am providing parent width and height (and have also attempted to set window innerHeight and innerWidth in various ways). Just a warning, but would love if we could resolve somehow.

 console.warn
    Can't get DOM width or height. Please check dom.clientWidth and dom.clientHeight. They should not be 0.For example, you may need to call this in the callback of window.onload.

      at Object.init$1 [as init] (node_modules/echarts/lib/core/echarts.js:2226:15)
      at EChartsReact.Object.<anonymous>.EChartsReactCore.getEchartsInstance (node_modules/echarts-for-react/src/core.tsx:89:68)
      at EChartsReact.Object.<anonymous>.EChartsReactCore.updateEChartsOption (node_modules/echarts-for-react/src/core.tsx:160:33)
      at EChartsReact.Object.<anonymous>.EChartsReactCore.renderNewEcharts (node_modules/echarts-for-react/src/core.tsx:114:34)
      at EChartsReact.Object.<anonymous>.EChartsReactCore.componentDidMount (node_modules/echarts-for-react/src/core.tsx:31:10)
      at commitLifeCycles (node_modules/react-dom/cjs/react-dom.development.js:20663:24)
      at commitLayoutEffects (node_modules/react-dom/cjs/react-dom.development.js:23426:7)
test('Renders scatter plot ReportWidget', () => {
  window.innerWidth = 1200
  window.innerHeight = 800
  render(
    <ApolloWrapper>
      <Router>
        <ThemeProvider theme={theme}>
          <div style={{ width: '600px', height: '400px' }}>
            <ReportWidget report="scatter" />
          </div>
        </ThemeProvider>
      </Router>
    </ApolloWrapper>
  )
})

Have also tried other ways of setting window size before the test, both in beforeEach() and in the test itself:

# Global provided by jest
global.innerHeight = 800
  global.innerWidth = 1200
# Object.defineProperty
  Object.defineProperty(window, 'innerWidth', {
    writable: true,
    configurable: true,
    value: 1200,
  })
  Object.defineProperty(window, 'innerHeight', {
    writable: true,
    configurable: true,
    value: 800,
  })

echarts 5.1.2 echarts-for-react 3.0.1 jest-dom 5.14.1

I use ECharts with vue 3 and I get this warning if I don’t set width and height (in that case, chart isn’t rendered). When I set width AND height, chart is correct rendered and I don’t get this warning.

In my case, I use ECharts with Angular (not ngx-echarts). I get this warning, but the chart is correct rendered/visible. It does not matter if I use ngInit or ngAfterViewInit. I think in the very first state of component loading, the container/layout is not yet fully loaded/sized. But it’s ok and no problem when using ResizeObserver (what should use ECharts build-in btw.). So the warning is annoying. We could offer an option to disable this checks/logs.

Btw. the warning is also displayed when using min-width, min-height to e.g. 1px.

Why should 0 be a valid value for a container? The warning here is to warn users that the chart is not visible most likely because the container doesn’t have width or height, in which case clientWidth or clientHeight is 0. Actually, they can never be undefined unless you assign so intentionally.

I have tried many options. This error disappears for me only when inline styles are set for the block. Namely inline styles in absolute units. Unfortunately, calc doesn’t work.

First option

  1. In javascript, during initialization, add size for block using inline styles.
  2. Initializing the chart.
  3. Remove this style from element and execute resize for the chart if it need (For example, when changing the browser window).
const chartDiv = document.querySelector('.chartBlock');
const baseWidth = window.innerWidth - 270;
const baseHeight = window.innerHeight * 0.45;
const chart = echarts.init(chartDiv);
chart.setOption(buildChartOptions(chartData));
 chartDiv.setAttribute('style', `width: ${baseWidth}px; height: ${baseHeight}px`);
chartDiv.setAttribute('style', `width: ${null}; height: ${null}`);
 
//Later (when the chart is ready and if you need responsiveness)
chart.resize({
      width: 'auto',
      height: 'auto',
    });

There may be errors in the example, since I write in a framework and there is a different syntax. But the point is clear.

If you don’t need responsiveness, then just add inline pixel styles to the div element.

Second option

You can simply use a timeout set to check that the block already has sizes.

  function chartCreator() {
    const chartBlockWidth = document.querySelector('.chartBlock').clientWidth;
    if (Number.isInteger(chartBlockWidth) && chartBlockWidth > 0) {
   //create chart
    } else {
      setTimeout(() => chartCreator, 100);
    }
  }

Version

4.2.1

Steps to reproduce

This warning from echarts: https://github.com/apache/incubator-echarts/blob/b6ab21159617b45c8077d998d468977cdd87d146/src/echarts.js#L1999 seems to be triggered when !dom.clientWidth, however I believe it is valid for dom.clientWidth to have a value of 0. I’m not sure why this warning was added, but I think the check should be dom.clientWidth === undefined if the check is for a failure of the clientWidth API to exist.

What is expected?

warning should not occur for element width/height of 0

What is actually happening?

warning is logged. I’m happy to resolve this issue, but I’d like some confirmation my hunch is correct, or a clarification for why it is not.

I got this warning because I using tab card, when page onload the container set by CSS with display:none . So I got this warning, but when switch the tab card, container will be assigned the width/height instead of 0. So for me just ignored this warn.

echarts-5.1.1: I was also getting this issue when a <div> containing the chart is initially set to display:none;

@zekraouin I’m using vue3 too, here is a different way to handle that issue and still want to use the autoresize feature:

<template>
  <v-chart v-if="showChart" :option="myOptions" autoresize />
</template>

<script setup lang="ts">
import { onMounted, ref } from "vue";
import VChart from "vue-echarts";

const showChart = ref(false);

const myOptions = {
  // ...
};

onMounted(() => (showChart.value = true));
</script>

in vue 3 , i have solved the issue by adding a div container with css : <div class="container"> <v-chart class="chart" :option="option" autoresize /></div> <style scoped> .chart { height: 100vh; position: relative;

} .container{ height: 350px; width: 400px; } </style>

Any update?

still no update?

Version

4.2.1

Steps to reproduce

This warning from echarts: https://github.com/apache/incubator-echarts/blob/b6ab21159617b45c8077d998d468977cdd87d146/src/echarts.js#L1999 seems to be triggered when !dom.clientWidth, however I believe it is valid for dom.clientWidth to have a value of 0.

I’m not sure why this warning was added, but I think the check should be dom.clientWidth === undefined if the check is for a failure of the clientWidth API to exist.

What is expected?

warning should not occur for element width/height of 0

What is actually happening?

warning is logged.

I’m happy to resolve this issue, but I’d like some confirmation my hunch is correct, or a clarification for why it is not.

I got this warning because I using tab card, when page onload the container set by CSS with display:none . So I got this warning, but when switch the tab card, container will be assigned the width/height instead of 0. So for me just ignored this warn.

Solved by resizing chart like this:

const chartRef = useRef<any>(null);

useEffect(() => {
    if (chartRef.current) {
      const chartInstance = chartRef.current.getEchartsInstance();
      chartInstance.resize();
    }
}, [])

return <ReactEcharts 
    ref={chartRef} 
    ... 
/>

echarts-for-react: v3.0.2

Is there any update to this? I see the issue has been closed so I’ll check if there is another one with a resolution

Hi there! Guys, I am getting this warning:

Can't get DOM width or height. Please check dom.clientWidth and dom.clientHeight. They should not be 0.For example, you may need to call this in the callback of window.onload.

And honestly I have tried with pretty much evertyhing:

  • Provide chart container with fixed height and width (something like 100px each).
  • Provide chart container with height and width both with auto as value.
  • Provide chart container with height and width both with 100% as value and other respective values like 100vh and 100vw.
  • Provide chart container with height and width directly from CSS.

No luck so far, I am using the latest version of ECharts and its React Wrapper and this is the only warning I was not allowed to clean.

    "echarts": "^5.1.2",
    "echarts-for-react": "^3.0.1",
    "echarts-stat": "^1.2.0",

Any help would be more than appreciated.

Thanks in advance!

The width and height of the container are required to create a canvas with the same size. So none of 0 or null or undefined is valid when init. Although we could provide a default canvas size when container size is not given, it may cause some confusions (e.g., the user has defined canvas CSS width and height, and the size is not the same with canvas size). Perhaps we should change the warning expression to make this information more understandable. But I don’t think providing a default canvas size when container size is a very good idea. Because first of all, setting container size is not a hard job for the user to do, as long as they know what’s wrong here. On the other hand, providing a default value that users don’t know how to change (calling resize) is a bigger problem.