You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But now, probably due to a bug introduced by latest versions of ChartZoom plugin, if you update the data/scale and then perform a reset zoom, the scale would be reseted to the 1st options while options are still correctly pointing to latest data
It turns out that the chartStates map in the originalScaleLimits still contains the data of the chart used by the constructor.
I still have not tested it yet, but I guess that doing a .destroy() and recreate the whole graph would work but it would defeat the purpose of the update method.
Moreover, I think that the behavior was correct a few version ago (not tested to roll back yet; and if the behavior that I have described is indeed a buggy one)
The text was updated successfully, but these errors were encountered:
Hi,
As I continue to work around with chartjs and the zoom plugin, I encoutered an issue with the latest version of zoom plugin.
Description
According to https://www.chartjs.org/docs/latest/developers/updates.html, One can use the update() method after updating either/both data and options to redraw the graph.
But now, probably due to a bug introduced by latest versions of ChartZoom plugin, if you update the data/scale and then perform a reset zoom, the scale would be reseted to the 1st options while options are still correctly pointing to latest data
Reproduction
A sample is available here:
https://codepen.io/Nico-DF/pen/poeKrRV
Do the following:
Trivia
I could trace it back to some code called by the resetZoom() function, it will use:
Which in turn, calls:
The getState is a shorthand to take back data from some WeakMap
It turns out that the chartStates map in the originalScaleLimits still contains the data of the chart used by the constructor.
I still have not tested it yet, but I guess that doing a .destroy() and recreate the whole graph would work but it would defeat the purpose of the update method.
Moreover, I think that the behavior was correct a few version ago (not tested to roll back yet; and if the behavior that I have described is indeed a buggy one)
The text was updated successfully, but these errors were encountered: