Re: [w3c/webcomponents] A new attribute similar to is="", but would allow multiple behaviors to be attached to a given element. (#662)

This effort could perhaps be pushed back to user land for prototyping if the issue was to be rebooted as some kind of "general mechanism for hooking into the lifecycle of custom elements". What if, for example, in addition to the current class constructor:

```javascript
CustomElements.define('my-element', class extends HTMLElement {});
```

 – the element registry was rigged to also accept a singleton object:

```javascript
CustomElements.define('my-element', {
 constructedCallback(elm) {}
 connectedCallback(elm) {}
 disconnectedCallback(elm) {}
 attributeChangedCallback(elm, ...args) {}
 adoptedCallback(elm, ...args) {}
});
```

 – which triggers on lifecycle events for all instances of `my-element`. The browser can create and register an anonymous Custom Element at least until the user does it, but the human user can choose one or the other approach to associate behavior with `my-element`, trading inheritance and local state for some kind of functional or stateless approach.

Or he can do both: Because you can register as many of these objects as you like, in addition to the single class constructor. The Custom Element will be associated with an infinite amount of behavior while the syntax in markup stays the same:

```html
<my-element>
<td is="my-element">
```

The `is` attribute then becomes safe for use in WebKit and the mechanism can be used in JS libraries to support experimental declarative mixin strategies as discussed above, perhaps to be included in the standard once the questions are resolved, such as: Who get's to own the Shadow DOM and how should the different behaviors interoperate (or not *), which seems to be a big enough challenge for Custom Elements as it is.

[*] By message passing via non-bubbling CustomEvents from the Custom Element, one could perhaps suggest, so the the current class hierarchy doesn't just become a hierarchy of class-clusters made of hard dependencies.

Just to illustrate how this might reduce the number of specifications spawned.

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