Lit-element: Uncaught (in promise) DOMException: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry

[lamianbu]

Description

@customElement('hello-view')
export class HelloView extends LitElement {
}

import './HelloView'; /* two file, import two times*/

Error is thrown:
Uncaught (in promise) DOMException: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry

if I do not use @customElement, instead for
if(!customElements.get('hello-view')){
customElements.define('hello-view', HelloView);
}

No error is throw

Live Demo

Steps to Reproduce

Expected Results

No error is throw

Actual Results

Error is thrown

Browsers Affected

• [ *] Chrome
• [ ] Firefox
• [ ] Edge
• [ ] Safari 11
• [ ] Safari 10
• [ ] IE 11

Versions

• lit-element: v2.2.1
• webcomponents: v2.2.10

[justinfagnani]

This happens if you define the same tag name twice, and is a platform behavior, not something that LitElement controls. Something in your loading / build system is double-loading a module with a custom element.

[Dyasik]

@justinfagnani Just wanted to figure out what is the reasoning between not handling this situation inside the lit-element?
I agree that double-loading is bad and developers should fix it. But why not be less disruptive and, for example, check if the element was already registered inside lit-element? And, for instance, show a warning in the console if it was? So that the developer can have his app working for the time being and let him handle the double-loading later. Especially when using the @customElement directive, when you cannot manually check whether the element has already been registered.

[justinfagnani]

@Dyasik the reason is that there's no right answer. Throwing an exception is the correct thing to do because it indicates that the application or component author didn't handle this case and decide whether execution and safely proceed.

If the app wants to patch customElements.define and make it not throw on duplicate definitions because it has made the determination that the second definition can use the first, it can. But there's no universal guarantee that the two definitions are compatible, so we can't do it automatically.

[leonheess]

@justinfagnani How would you patch customElements.define like this?