- From: Steve Orvell <notifications@github.com>
- Date: Mon, 08 Jan 2024 14:36:21 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1043@github.com>
**Background** As [currently spec'd](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md), registries are coupled to Shadow DOM and require a new opt-in API to facilitate scoped element creation (`shadowRoot.createElement/importNode`). While this makes good sense for the first version of the API, there are some additional use cases that could be addressed by expanding the API in the future. **Use case** In particular, the[ micro-frontend architecture](https://micro-frontends.org/) (MFE) is a natural fit for web components because of their native interoperability but fundamentally requires scoped registries. However, MFE's often exist in complex environments where various web frameworks are used together. For MFEs to effectively use scoped registries, ALL frameworks used in them must be aware of and use scoped API for creating DOM. Currently, of course, none of them do. While this can be addressed in the long run, it's sure to be a point of friction and it'd be great to expand the API to more seamlessly support this use case. **Example** An MFE feature is implemented with [React](https://react.dev/). The feature itself (inside the React components) uses custom elements. Currently, this means the React MFE feature should itself be wrapped in a Shadow DOM which uses a scoped registry to define those custom elements. So far so good, but now there's a problem: React doesn't know about `shadowRoot.createElement` so it doesn't create the correctly scoped elements. An un-upgraded element connected to a shadowRoot with a registry will upgrade with the registry's definition so the only practical problem is a conflict with a globally registered element. **Possible solution** It's tempting to propose adding a way to apply a registry to a DOM subtree that doesn't use Shadow DOM. However, while this might be useful for frameworks that don't expect Shadow DOM for other reasons (e.g. reliance on global styling), it wouldn't typically help solve this problem. That's because it's a very common pattern for frameworks to create elements via `document.createElement`, and any globally registered element will immediately upgrade on that call. This should be verified, but I believe the most common pattern generally used by most web frameworks to create DOM is `document.createElement` + "append." So if there were a general custom elements feature to specify "for this name, only customize the element via upgrade and not creation." Ideally, this could be done independent of the global registration but this could arguably be too powerful. Some API options for how to do add `upgradeOnly` feature: * at define time: `customElements.define('x-foo', XFoo, {upgradeOnly: true});` * Pro: explicit * Con: requires knowing that this could be a problem * dynamically: `customElements.customizeWhen('x-foo', {upgrade: true})` * Pro: dynamic and could be done if/when/as needed. * Con: changes existing behavior and therefore could violate expectations (perhaps could require an opt-in setting to enable on the registry itself) * whenever a name is used in a scoped registry: notGlobalRegistry.define('x-foo', XFoo) * Pro: seamlessly automatic * Con: same changes existing behavior issue -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1043 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1043@github.com>
Received on Monday, 8 January 2024 22:36:29 UTC