[scoped-registries] CustomElementRegistry to support SDLC of generic browser entities

[sashafirsov]

The most of APIs for objects in browser do support CRUD operations. But for custom element registries it has been implemented only partially.

• Create - i.e. registration covered by Scoped Custom Element Registries and partially in original API
• Read - CustomElementRegistry.get() is partial implementation. Does not allow to
  • list the registered tags
  • watch for list changes
• Update - replace the implementation. Facade pattern to
  • semver support in init time,
  • live app upgrade
  • translation
  • analytics
  • ...
• Delete - unregister. The proposals been closed on several occasions. A base for Upgrade ^^

The exact API is a subject for individual discussions.

[sashafirsov]

@justinfagnani , as author of Scoped Custom Element Registries, do you think the browser objects APIs should follow same patterns?

[justinfagnani]

I'm confused by this issue. I don't know what SDLC is and I'm not sure how CRUD relates to objects or most browser APIs that are not database-like.

The Scoped CustomElementRegistry proposal is focused on associating registries with DOM trees. I think additional API changes for CustomElementRegistry, like unregistering elements, are out of scope for that proposal, and already discussed in issues like https://github.com/WICG/webcomponents/issues/754.

[sashafirsov]

SDLC - software development life cycle. Referred here as support full life cycle of CustomElementregistry for developers and apps. Which is including creation, inspection, reuse/clone, customize, ... remove.

CRUD is not only DB term. Any object lifecycle in browser includes basic operations: creation, inspection(read), modification(update), delete. I bet there are some more. Like the string conversion for log, serialization (JSON, XML, binary,)...

The Scoped CustomElementRegistry proposal is focused on associating registries with DOM trees. I think additional API changes for CustomElementRegistry, like unregistering elements, are out of scope for that proposal, and already discussed

It is understandable that particular object (CustomElementRegistry) main behavior is the primary subject for proposal. But symmetrical API either has to be assumed by default or outlined why there are exceptions for this kind of object.

I see the lack of operations described in story as missing symmetry in API. When other collection APIs in browser been implemented, most if not all been symmetrical.

@justinfagnani , is there a reason to break symmetry? The arguments of #754 was not accounting for generic collection capabilities, rather was an intent to artificially insulate one of collection use aspects.

[justinfagnani]

Is this an issue asking to re-open #754 with a new consistency argument?

[sashafirsov]

@justinfagnani , this is new consistency argument not just for #754 but also whole set of collection interfaces.