Re: [WICG/webcomponents] Scoped Custom Element Registries (#716)

> I also think it would be a source of confusion if your custom element stopped working after adding scoped custom elements. There would be a lot of StackOverflow questions about it! 😄

This is a _really_ good point. Suppose we took this problem to JavaScript. Imagine that we took this code

```js
let foo = 123

function doIt() {
  console.log(foo)
}
```

it would be very surprising and unexpected if writing

```js
let foo = 123

function doIt() {
  let bar = 456
  console.log(foo)
}
```

suddenly caused the `console.log` to start outputting `undefined`.

In this same manner, I feel as if there _has_ to be fallback lookup. We have some options (Option 3 is my favorite):

1. Specifying a `downgrade` operation for custom elements might be useful: if a custom element was upgraded to a global class because the local scoped registry didn't have a class defined, but then later the registry gets the class defined, the element can be downgraded before being upgraded to its new class.

2. Any elements already upgraded to a higher-registry's definition, before a scoped registry gets a definition, stay with the original class. Elements inserted after the scoped registry has the definition take on the new definition.

3. Once a scoped registry is live (belongs to a shadowroot that is connected into a document) all higher-registry definitions that aren't contained by the scoped registry have been inherited and all of the scoped registry's definitions become permanent (we can not add new ones). This would require people to think ahead, and to pre-define a scoped registry's definitions prior to making the registry live. Once live, definitions are permanent in the same sense as how we cannot arbitrarily add or remove variables from a function scope.


Option 3 is the "type safe" way to do it: the developer has a higher chance of knowing ahead of time what elements they will use in their program. Everything works as expected (for the most part): no gotchas, unexpected results, or bugs resulting from elements accidentally treated as the wrong type of element, or resulting from upgraded vs not-yet-upgraded elements (one of the banes of custom elements development), etc.

I say "higher chance" because the global registry is still dynamic, and definitions can be added any time after it is already live (it is already live from the start of a web app).

> ```js
> this.attachShadow({
>   mode: 'open',
>   customElements: {
>     MyInput,
>     SomeWidget,
>   }
> })
> ```

This is interesting, and enforces type safety. 👍 We pre-define what we'll use, with no surprises, and no difficulties from having to think about pre-upgraded instances.

Having to handle pre-existing property values from pre-upgrade instances with the class fields `[[Define]]` abominable snowman being in the way makes things _extremely_ difficult.

Unfortunately, even with the type safe approach, `cloneNode` does not construct custom elements, which still poses the pre-upgrade problem for anyone using that API (like many DOM template libs like to use).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/716#issuecomment-1032157678

You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/716/1032157678@github.com>