-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
releasing charts from the chart registry #1119
Comments
Thinking on it, I may have run into this as well. I certainly ran into a similar-sounding slowdown case in my SPA which I seem to have fixed by calling Would be nice to have an in-library solution, of course. |
Do you have any suggestions for how this could be done automatically? It seems to me that the client creates the charts and only the client will know when they should be destroyed. I doubt that you don't use the chart groups, because the chart groups are used to implement reaction to filters. |
I was thinking of suggesting something along the lines of "remove the chart if another one is defined in the same chart group with the same ID", but then I got to thinking: dc doesn't (AFAIK) have a concept of "chart ID" other than its parent selector (maybe). Can you put more than one chart on the same parent? I've never tried. |
Most SPA frameworks have some lifecycle hooks. A common one would be an event when a component is removed from the DOM. just do something like this for your chart component: component.onunload = function(){
dc.chartRegistry.deregister(component.chart, component.chart.chartGroup());
component.chart.dimension().dispose();
} @gordonwoodhull a way to reliably detect whether a chart is indeed active would be something along the lines of:
Which is really expensive. |
I'm idly curious on how the performance impact of Huge DOMs exist, though, so an auto-deregister would likely need to be opt-in. Just a mental note to try some profiling later-ish (given the time, of course). |
I think using the framework hooks is a better option here, or if you know when everything is getting replaced, I don't like the idea of scanning to see if charts are still on the page - it's slow and seems error-prone to me. But it might be okay if it's under an option. |
@also, returning to @tlrobinson's original question, specifying the group name is equivalent to having access to the group object. Maybe a little awkward but it should serve the purpose. I think the chart registry should be spun off into a small specialized library based on d3-dispatch (#988) and we should be able to provide a nicer interface at that level while preserving the existing legacy interface. |
Hoooooo. |
hi @gordonwoodhull , this issue been opened 4 years ago and still not close yet. Am I right to assume the calling |
There are quite a few suggestions in this issue for how to release charts from the chart registry. I still don’t see how dc.js can do this automatically and I think it’s up to the client to figure that out. So I guess I’ll close this. |
Is calling thanks. |
As far as I know, that should release the resources. If you encounter any leaks, please file an issue. |
If you have a single-page application that renders charts, throws them away, renders more charts, etc (as we do over at https://github.com/metabase/metabase) it appears
dc.chartRegistry
holds onto a reference to every chart ever rendered by dc.js forever (and thus the data used by every chart as well).This seems unfortunate. I think it would be better to explicitly create a chart group object that you add charts to (or not, if you don't need that functionality).
In the meantime, is the recommended solution to just call
dc.chartRegistry.deregister(chart)
if you know you're done with a chart?Or if you don't use chart groups at all is it safe to just do
setTimeout(() => dc.chartRegistry.clear(), 10000)
or something?The text was updated successfully, but these errors were encountered: