idempotent/soft customElement decorator

[gullerya]

Description

• We at Vonage using the Lit library as both a stand-alone and as part of MWC components, we are building on
• There are cases, see TLDR, actually always, that we need customElement decorator to behave in somewhat-idempotent fashion: define an element only if there is no such an element defined in the registry
• See TLDR below
• defining the component named my-component twice won't throw

Acceptance criteria

Defining the component named my-component twice won't throw

TLDR;

The below assumptions are leading to an issue with current, strict, customElement decorator behavior:

• when someone delivers web-component to the world, it is a usual practice to perform the actual component definition/installation/registration as part of the immediately invoked component's module flow (this is what MWC do as well)
• it is not possible today to manage scoped custom element registries and the spec discussion on that topic seems to be a years from now till some practical resolution
• when even the same component imported form different locations it'll attempt to register self more than once and the whole dependee module init fail
• it is not convenient / possible to enforce importing the component form the same location (URL specifier) in cases when different parts of the application delivered / built separately (micro frontends approach as an example)

Downsides (tolarable from our POV, but probably require attention from your side as a platform):

• different versions of the component may be not deterministically defined at runtime

If the non-deterministic downside is a major concern, the decorator may:

• by default NOT allow soft skip over
• allow skip over as opt-in as a decorator's init function parameter
• allow skip over as opt-in + warning in console / callback to the consuming application to perform decision at each point (might be lesser and future priority, when the skip-over behaviour found useful, if any).

[sorvell]

This isn't something we want to include in the core library, but you should feel free to create your own decorators for these types of use cases. Please open a new issue if you need guidance on how to proceed. Thanks!