I created two WebComponents by Vaadin 14.1.5.
started Jetty on two different ports.
If I try to use only one WebComponent of them in a static html file - everything works fine.
But if I try to use both, the Browser flashes some times and writes: VM2752:1 Uncaught Application ROOT-2521314 is already being initialized Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "dom-module" has already been used with this registry
… but for all that it renders both WebComponents. These WebComponents are very simple (only a <div/>).
In another scenario with much more complex WebComponents I get the same console error and only one of the WebComponent is rendered.
How can I get it work: Using two Vaadin 14 WebComponents hosted on different Servers?
This is a limitation of web components by design. You can’t import two different versions any component, e.g. vaadin-button and use it on the same page (except if you are using iframe).
And Polymer that we currently use defines several custom elements on its own, and dom-module is quite common (in fact, it is used by every of Vaadin components, both in Polymer 2 and 3).
It’s still possible to split your app into independent parts, or “micro frontends”. But we recommend to use the same component bundle for those parts. See https://vaadin.com/labs/micro-frontend for an example.
Let me explain a bit more. When using ES modules, browsers de-duplicate requests to them, so each individual module with a given URL is only executed once.
However, when you serve the same file using different port, the URL changes. So the browser is no longer able to de-duplicate it, and it executes the module again, resulting in duplicates.
Why the scripts cannot test at the beginning if they where executed before?
One reason is the case that there are different versions of the same script. There may be some logic that requires features that are only available in one of the versions so just using whichever was loaded first may or may not work.
Another reason is that it solves the problem in the wrong end: why even have the user’s browser download scripts that won’t be used? It would be much more efficient for the user (especially in situations when network capacity is limited) if they wouldn’t have to download the additional scripts at all.
