Re: [WICG/webcomponents] Lazy Custom Element Definitions (#782)

What if instead of the lazy callback needing to return a custom element, the callback received an object with an API it could use to optionally define the element later? The platform could invoke the callback when it first sees the element, but the lazy callback could choose when it wants to actually define it. If it wants to use MutationObserver semantics, it would just return the custom element as shown in the original proposal. This provides nice ergonomics for the simple case. If it wants to use IntersectionObserver semantics, it would create an observer and then use it to call define at a later point in time. It could use any mechanism to determine when to define, such as based on attributes, mouse proximity, or even perhaps defer loading using the microtask queue so that it could batch requests for multiple element definitions that were seen by the browser in the same tic.

The API could look something like this:

```ts
interface IDefineLazyElement {
  readonly element: HTMLUnknownElement;
  define(type, options): void;
}

lazyDefine(tagName: string, callback: (d: IDefineLazyElement) => Promise<void | Constructor>
```

Additionally, we could explore `tagName` supporting patterns in the future. We may also want an option to invoke the callback on first sight vs. on every sight until it is defined (or at least we need to discuss this).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/782#issuecomment-1523653726
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/782/1523653726@github.com>