Different versions of model viewer in the same DOM

[fivelive]

I’m thinking of a scenario where I would want to dynamically add a model-viewer element on a customer’s website, not knowing if that website already has a model-viewer script tag in its DOM.
(Note: I'm talking about the script tag to import model-viewer, not the model-viewer tag itself).
Also, if that website already has a model-viewer script tag in its DOM, now the issue would be the version of the existing model-viewer script tag. (Assuming that I need to work with a specific version of model-viewer).

If a model-viewer script tag is already in the DOM and we try to include our own model-viewer script tag, the CustomElementRegistry will throw an exception, because the "model-viewer" custom element name is already in the registry. Thus, the model-viewer version used will be the one of the existing script tag.

The only solution I can think of to be able to use a specific version of model viewer in my dynamically added HTML on a customer's website would be this:

Have a custom distribution of model-viewer with a different custom element name (ex: my-model-viewer).
This way, there would be no conflict in the CustomElementRegistry when trying to include my own script tag, and by using a my-model-viewer tag, also making sure to use the specific version I need.

Does that make sens? Could it have some side effect I'm not aware of?
Is there any better solution to this problem?

Thanks

[cdata]

@fivelive thanks for reporting!

Have a custom distribution of model-viewer with a different custom element name (ex: my-model-viewer).

I think this is probably the most pragmatic approach. There is a future feature called Scoped Custom Element Registries that might give you a better option someday, but for now I would recommend that you just have a custom build that uses a specialized tag name.

Another thing you could try, if are willing to make a custom build and you want to get fancy, is something like this:

let number = 1;
let tagName = 'model-viewer';

while (customElements.get(tagName) != null) {
  tagName = `${tagName}-${++number}`; // Try model-viewer-2, model-viewer-3, model-viewer-4 etc.
}

customElements.define(tagName, ModelViewerElement);

But in practice, you are probably safe 99% of the time if you just pick a unique tag name like <mycompany-model-viewer>.

That said, the main areas (that I can think of) that could cause problems are the following:

1. If you do anticipate that more than one <model-viewer> is on the page, keep in mind that right now model-viewer.js is a very large JavaScript bundle, and the end-user probably won't be very happy to view a website where they have to download it twice. We have plans to make this better (e.g., Enable 3DOM to be lazy loaded #931 , Enable Three.js to be lazy loaded #337 ), but for now you would have to manually optimize the bundle to mitigate this issue.
2. If our code ever attempts to count the number of <model-viewer> elements on the page, it will probably do so either by keeping track of connectedCallback/disconnectedCallback invocations, or by counting constructor calls, or by doing document.querySelectorAll('model-viewer'). If you load two different <model-viewer> implementations on the page, they probably won't be able to correctly account for each other. We plan to use the number of instances to decide how to do rendering under the hood (see Offscreen canvas #995), and we might choose the wrong optimizations in cases like this.
3. Our caching mechanism will be sharded by the number of distinct bundles that bring in the <model-viewer> module graph. This means that if you load both model-viewer-1.js and model-viewer-2.js, <model-viewer-1 src="Astronaut.glb"> and <model-viewer-2 src="Astronaut.glb"> will cause the Astronaut.glb to be loaded and cached twice. This is bad both in terms of network usage and device memory usage.

There are probably other caveats, and I'll try to document them for you if I think of them. In general, it should be feasible for you to define multiple, different tags for ModelViewerElement, and we will try to support that in case there are bugs. However, I would strongly encourage you to consider the performance consequences of loading multiple model-viewer.js bundles on a given page! We have seen iOS Safari crash after loading just a few models at once (due to low memory ceiling) and there is nothing we can do to fix that for you when it happens.

[fivelive]

Waouw! Thanks @cdata for this complete answer, you really helped here.
Yes, if you ever see any other downside, do not hesitate to share it.
Thanks again!