[scoped-elements] Detect & act on number of implementations

Hey,

Feature request here.

As far as I understand it is possible for the ScopedElementsMixin to detect how often a certain component tries to register on the custom element registry through scopedElements getter, so it could count for e.g. lion-feedback scoped element, how often it registers. In addition, on the first time, we could even test if it’s already registered under unscoped lion-feedback (e.g. from an old version that doesn’t use the ScopedElementsMixin).

That way we can count the amount of implementations for a specific element, for example for an app using three features that rely on v1 of lion-feedback, v2, and v3 respectively.

Why is that useful?

Because now we can error out, or warn, through a flag e.g. maxImplementationCount, for example if set to 1, it would error on runtime if you have more than 1 lion-feedback, regardless of whether it is unscoped or scoped. This is something that may help people troubleshoot a bit (and guard for) more how many versions of the same element are being registered, by which of their dependencies this is caused, etc.

Flow

• lion-feedback (v1) can be registered normally through explicit side effect file that does customElements.define('lion-feedback', LionFeedback).
• LionFeedback (v2) class gets imported and scoped through ScopedElementsMixin as lion-feedback-12345, but the mixin also sees that lion-feedback already exists as it is on the registry --> implementation-count for this component = 2
• LionFeedback (v3) class gets imported and scoped as lion-feedback-45678 --> implementation-count for this component = 3

Problem I see here is: what if lion-feedback (v1) file gets loaded last, then the mixin doesn’t know about it and the implementation-count would be 1 lower than actual count? Could the mixin somehow listen to the CustomElementRegistry registrations for names being added that are also existing keys in the mixin?

[LarsDenBakker]

I think we can implement this as a decorator on the global customElementa.define separate from the scoped elements mixin that also prevents race conditions.

[frank-dspeed]

@jorenbroekema ah ok sure that’s also a legit case for this. i agree but still counting how often something registers does not help any way I am out 😃

but for the version management, I would choose npm ls component-name but i now fully understand your case you need it as a dev tool 😃