developit / developit/element-worklet

What if the custom element author wishes for the end user to define the element name?

Open
#1 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
31
Forks
0
PR merge metrics
No merged PRs in 30d

Description

A pattern seen in some custom element libraries is that they allow the end user to import the class, and for the end user to decide with which name to call `customElements.define()`.

For example, an end user can do this:

```js
import {NiceElement} from 'some-library'

// End user chooses the tag name:
customElements.define('cool-element', NiceElement)

const el = document.createElement('cool-element')
```

Maybe we should allow this pattern to still be possible with Element Worklets.

For that to be possible, maybe the worklet can call `customElements.define` like the proposal already shows, but maybe also the end user can call it if the worklet doesn't. The alternative form might look like this:

```ts
// nice-element.js

// Use a default export to denote the class for the ElementWorklet perhaps:
export default class NiceElement extends WorkletElement {...}
```

Then the end user can register the element:

```js
// end-user.js
customElements.defineWorklet('cool-element', 'path/to/nice-element.js')

const el = document.createElement('cool-element')
```

Or maybe we can rely on the [stage 3 import assertions proposal](https://github.com/tc39/proposal-import-assertions) (I feel like the "import assertions" naming is strange). It could look like this:

```ts
// nice-element.js
// This is not a default export (the author can use any type of export):
export class NiceElement extends WorkletElement {...}
```

```js
// end-user.js
import {NiceElement} from 'path/to/nice-element.js' assert { type: "element-worklet" }

// customElements.define would automatically know how to handle WorkletElement proxy classes:
customElements.define('cool-element', NiceElement)

const el = document.createElement('cool-element')
```

`assert` doesn't quite match the semantic though. It seems that `assert` is for asserting mime types, but the worklet would have the same mime type as any other JSON file. So maybe some other sort of "import attribute" would be needed in a follow on like that proposal mentions:

```js
import {NiceElement} from 'path/to/nice-element.js' with { elementWorklet: true }
```

or something?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.