Cannot read properties of null (reading 'getContext')

[icebob]

Expected behavior

Handle when the this.canvas is null.

Current behavior

We have a statistics web app with multiple pages with multiple charts and when we change the pages, (if it's as fast as ~1 second) sometimes the chartjs throws an error and after that, all charts disappear and never appear again, just after F5.

chrome_EU2BlEhWMr.mp4

This problem does not happen if the animation is turned off.

Reproducible sample

https://codesandbox.io/p/sandbox/vue-chart-3-chart-js-issue-template-forked-f2gkpm

Optional extra steps/info to reproduce

Press the buttons one after the other quickly.

Possible solution

Based on the stack trace, It looks the clearCanvas doesn't handle if the canvas is null

Chart.js/src/helpers/helpers.canvas.ts

Line 135 in 1777f95

ctx = ctx || canvas.getContext('2d');

Context

The error:

helpers.canvas.js:119 Uncaught TypeError: Cannot read properties of null (reading 'getContext')
    at clearCanvas (helpers.canvas.js:119:23)
    at Chart.clear (core.controller.js:268:5)
    at Chart.draw (core.controller.js:718:10)
    at core.animator.js:89:15
    at Map.forEach (<anonymous>)
    at Animator._update (core.animator.js:60:18)
    at core.animator.js:45:12

chart.js version

v4.2.1

Browser name and version

Chrome latest

Link to your project

No response

[sun]

I was facing the same issue and updating to the latest version of chart.js resolved it. 👍

Now I'm seeing more or less the same error, just from a different source:

Uncaught TypeError: Cannot read properties of null (reading 'save')
    at clipArea (helpers.canvas.ts:329:7)
    at Chart._drawDataset (core.controller.js:798:7)
    at Chart._drawDatasets (core.controller.js:772:12)
    at Chart.draw (core.controller.js:724:10)
    at core.animator.js:89:15
    at Map.forEach (<anonymous>)
    at Animator._update (core.animator.js:60:18)
    at core.animator.js:45:12

My chart uses responsive, but does not have a custom clip area defined; this seems to happen by default.

I'm a bit surprised that so few people are running into this issue. Because I'm facing this in Vue 3 with a fairly simple bar chart that can be viewed in different timeframes triggered via buttons, which are then loading the requested data. Is this use case so rare or are we (including the OP of this issue) doing something wrong?

For the time being, I'm working around the issue by reducing the animation duration from the default 1s to 250ms, in the hope that users are not switching between timeframes faster:

{
  chartData: {
    options: {
      animation: {
        duration: 250
      }
    }
  }
}

[binonhq]

Does this issue been fixed? I still got this issue with v4.5.0

[amaztony]

Does this issue been fixed? I still got this issue with v4.5.0

Same. But it's my fault. try not to update the chart while it's playing animation.

[jaime018]

Temporary solution

This code is used to prevent errors that happen when there is a conflict between Vue's component teardown process and the cleanup process of an external library like Chart.js.

The Problem: A Race Condition 🏁
When a Vue component is unmounted (e.g., when you navigate to a different page), the onBeforeUnmount hook is triggered. At this exact moment, two things can happen simultaneously:

Vue's Cleanup: Vue begins to synchronously remove the component's DOM elements and dismantle its reactivity system.

Chart.js State: The Chart.js instance might still be active, especially if an animation is running.

If you call chartInstance.destroy() directly inside onBeforeUnmount, you create a race condition. The chart library might try to access a DOM element or a piece of data that Vue is actively removing. This results in errors like Cannot read properties of null because the resource the chart needs has suddenly disappeared.

The Solution: Decoupling with setTimeout(..., 0) 🕰️
The setTimeout function with a 0 millisecond delay is a standard JavaScript technique to solve this kind of race condition.

It works by deferring the execution of the chart destruction code. Instead of running immediately, it places the function at the end of the execution queue, to be run on the next "tick" of the event loop.

This small delay is critical because it allows Vue to completely finish its unmounting process first. By the time the setTimeout callback function executes:

The Vue component and its DOM elements are already gone.

The Chart.js instance is effectively a "zombie" object, detached from the page but still held in memory.

At this point, calling chartInstance.destroy() is perfectly safe because it can clean itself up without conflicting with Vue's lifecycle, thus preventing the error.

onBeforeUnmount(() => {
  const chartInstance = chartJs.value; // Use the variable name appropriate for your component (e.g., barChartJs.value)

  if (chartInstance) {
    // Completely decouple the Chart.js destruction logic from Vue's synchronous destruction cycle.
    setTimeout(() => {
      try {
        // This code will execute after the Vue component has been completely destroyed.
        chartInstance.stop();
        chartInstance.destroy();
      } catch (e) {
        console.warn('Error during deferred chart destruction:', e);
      }
    }, 0); // A 0ms delay defers the task to the next event loop tick.
  }
});

감사합니다. @amaztony @binonhq