D3 rendering in custom widgets - v7 vs v3

Hi Tessa, thanks for checking in with this interesting piece of work. I like creativity like that, and the fact that you’re sharing it.

However, that remark alone does not solve your problem. In fact, it might be difficult to solve. But I wouldn’t call it impossible either.

Looking at your code I see that you’re actively trying to load the D3 version that you think you and other widgets might need, at a certain point in time.
What you’re code does not control (and cannot control, so you’ll need a different approach) is the timing of all this loading and swapping of versions. Which, I think, makes it likely that the ‘available D3 version’ is often not what a widget might think it should be. After all. when the page is loading, widgets instantiate at unpredictable times, in theoretically random order. And it gets even more unpredictable for you, since I think you are trying to do the ‘swap thing’ every time the chart needs to be drawn. Which might also occur more than once while the widget options resolve or while data changes or comes in.

So v3 and v7-dependent code is running all at almost the same time, in orders you cannot predict. And your code is probably repeatedly inserting the script again and again, manipulating the availability of the global too.

The main issue then of course is: all widgets (including yours) depend on a globally available D3, on the window object. Our code does, partially at the least. And I have to say: diving into some parts of the code, with the the limited time I can currently spend on this, revealed to me that I see some odd mixes of v3 and v7 in our code as well. But it is clear the global d3 object (for v3) is crucial for it all to function on the WebUI side.

What your widget code would want to do is load D3 as a module. similar to how our ‘mixed code’ also uses v7 like that. So it has its own namespace and does not conflict with other WebUI code. Also, loading it only once is probably nicer.

I’m not sure if this will work in ASR, since we don’t load that code ‘as a module’ itself, but following the lines of the D3 docs (https://d3js.org/getting-started#d3-in-vanilla-html) I would expect you to be able to have an import of d3 like this (and if you’re not using this CDN version they suggest, do make sure you point to a script that supports being loaded as a module):

import * as d3 from "https://cdn.jsdelivr.net/npm/d3@7/+esm";

To be even more safe, I’d rename d3 to d3v7 and use that in your drawPieChart method instead of passing d3 as an argument like you do now, after the ‘loading’ resolves.

However, I have not investigated whether it is possible to even do so, nor how D3 has this option to load as a module. But the key is: load once and load it into a different namespace.
I’d certainly not try and manipulate the global, for the sake of the stability of our and your code.

As incomplete as this answer is, I hope it serves as some inspiration for changes you can still make.