Has anyone else experienced an issue where if you use the native WeWeb charts, they tend to completely cripple or even crash Safari when opening the production app? They don’t seem to even render properly in Chrome when developing, and they are missing in Chrome in production, but they completely cripple Safari in production.
In some older projects, this is not the case when using the Charts.js extention/plugin, but I can’t seem to find/add it in the new WeWeb Unify projects.
Has anyone experienced this and/or found a way around this?
Ok we’ve deep dived this a bit more and can confirm the below:
We’re hitting a reproducible lock-up with ww-chartjs. Mounting a chart is fine; updating one that’s already mounted is not. Any control that changes a chart’s data or options while the element stays in the DOM — range chips, a date picker, a select — makes Safari unresponsive and drags the whole machine down with it. Force-quitting Safari recovers it. Chrome is unaffected, though there the charts often fail to render in the editor canvas while being fine in production.
The signature is worth noting because it rules out the obvious explanation: Web Content CPU stays flat while WindowServer fluctuates and a process named after the app’s URL climbs steadily in memory. It isn’t a JS loop in a binding — it reads like GPU/compositor pressure from repeated canvas work. A theme switch triggers it too, which took us a while to spot: chart colours are read from design tokens inside the bindings, so flipping light/dark rewrites data and options for every chart on screen without touching a chart control.
Our workaround is to rebuild the chart rather than ever update it. A single shared boolean is ANDed into every chart’s conditionalRendering, and every control that changes chart data sets it false, changes the data, waits ~60ms, then sets it true. The wait is load-bearing: setting the flag false and true in the same synchronous run gets coalesced by Vue’s microtask queue, so the element never actually unmounts and you get exactly the in-place update you were trying to avoid.
What would fix this properly is for ww-chartjs to destroy and recreate its Chart.js instance when the data/options identity changes, instead of mutating the live one — or to expose a prop to opt into that. It’s the same workaround, but done inside the element where it can call destroy() and drop the canvas rather than repainting it. Failing that, documenting that the element updates in place would at least tell people that a remount is the lever when they hit this.
Thanks so much for taking the time to share the solution on here. I’ll share it with the team so they can explore ways to improve the in-product / doc experience.
