- From: Filimon Danopoulos <notifications@github.com>
- Date: Tue, 01 Oct 2024 00:52:35 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1074/2385045225@github.com>
@keithamus Thank you for the in depth reply. It provides the context I need to understand what I am asking about. Being new to this space there is a lot arcana to try and figure out. > - Are many people trying to do this today? > - If so why? What problem does it solve? Are you prepared to talk about the problem space in abstract (without mentioning anonymous elements) that makes a convincing case? I have personally done random tag name generation before. The primary use case was as in order to provide a wrapper for frameworks to use scoped elements. Assume I have the component `<some-element>` that internally uses some scoping, it can be the scoped element registry or some other mechanism. In my case I did a transform of tag names in bundle time. The end result is `<some-element>` that for all intents is "scoped". If I distribute this as an NPM package I can easily get a situation where multiple people register the same constructor and same tag name, in particular in MFE-type settings where multiple bundles are used on the same page. This effect is only amplified by import maps since I then can into the situation that multiple bundles can use the same ES module and constructor so we don't only get tag name collisions but also constructor collisions in the registry. So I'd essentially generate (JSX for the example) ```js import { SomeElement as SomeElementBase } from '@elements/some-element.js' custom.elementsDefine('some-element-1234', class extends SomeElementBase {}) export function SomeElement() { return <some-element-1234></some-element-1234> } ``` This combined with import maps can create essentially ESM scoped web components. At the same time this is sort of defeats the point of using web components in the first place since we are forced to produce framework wrappers. The abstract need without discussing specifics would be to import a custom element constructor into an ES module and attach an instance of that to the DOM. We can always generate tag names at each call location: ```js // my-example.js export class MyExampleElement extends HTMLElement { static getTag() { const tagName = `my-example-${crypto.randomUUID()}` customElements.define(tagName, class extends MyExampleElement {}) return tagName } } // index.js import { MyExampleElement } from './my-example' const tagName = MyExampleElement.getTagName() const myExample = document.createElement(tagName) // ... ``` All that being said @justinfagnani makes a good point regarding generated names > It's often a bit trickier to use generated names in template systems and CSS This would probably require some framework specific wrapper regardless, rendering the entire concept invalid. @Jamesernator I assumed this had been brought up before. I was a little hesitant to raise an issue but figured that there are no stupid questions :) -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1074#issuecomment-2385045225 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1074/2385045225@github.com>
Received on Tuesday, 1 October 2024 07:52:39 UTC