38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
# Controller-Registry
|
|
|
|
A prototype for an alternative to custom elements.
|
|
|
|
## Concept
|
|
|
|
Similar to a custom element, a controller defines custom behaviours for HTML
|
|
elements and is managed automatically by a registry.
|
|
|
|
Like custom built-in elements, controllers are controlled via an attribute on
|
|
the element.
|
|
|
|
Unlike custom elements, controllers are external objects or functions that are
|
|
attached to an object, meaning several different controllers can be managing the
|
|
same element at once, and the class of the element does not change in the
|
|
process.
|
|
|
|
Controllers can be added and removed as necessary.
|
|
|
|
## API
|
|
|
|
The library exports a global `ControllerRegistry` attached to the document root
|
|
with a similar API to the `CustomElementRegistry` class.
|
|
|
|
Controllers can be registered under any name as either a callback which gets
|
|
called when the controller is added to an element or a constructor which gets
|
|
called with `new` and passed a revokable proxy to the element.
|
|
|
|
If the controller is a function, the second argument is a promise that resolves
|
|
when the controller is removed again. This promise has an additional property
|
|
`"signal"` which returns an `AbortSignal`. This means the promise can be passed
|
|
directly as the third argument to `addEventListener` function calls.
|
|
|
|
The registry also exposes a `list` function which, given an element, returns an
|
|
object similar to a `DomTokenList` for easier management of the controller list.
|
|
|
|
The `controller` attribute is a space-separated list of controller names as
|
|
registered in the registry.
|