Re: [w3c/webcomponents] How to define APIs only for custom element authors (#758)

Extendung from option 3, could the following help with performance?

*Option 4:* `static` list of features.

 What if elements could specify specific features to use in a static prop, so the engine doesn't unnecessarily have to pass every single feature into a callback even if an element won't use each feature?

F.e.

```js
class Foo extends HTMLElement {
  static get observedAttributes() { ... }
  static get features() { return [ ... ] }
}
```

Then the features could do what they want: specify new callbacks, or provide certain instance props, etc.

Either it would be up to the feature how it is exposed, or perhaps they all get injected into a standard callback like option 3's `createdCallback` (though I think a different name would be better because we already have `constructor`).

As for the static list of features, if they were strings it would be easiest, but with the problem of name clashing (suppose we let anyone provide features, not built-in features):

```js
  static get features() { return [ BuiltinFeature, UserFeature ] }
```

References would avoid name clashing, and not require a registry:

But then, this seems like mixins!

*Option 5:* class-factory mixins

Could mixins do the trick?

```js
class Foo extends BuiltinFeature( UserFeature( HTMLElement ) ) {
```

The features if the web component library [SkateJS](http://skatejs.netlify.com) are consumable as mixins, for example, which works great.

-- 
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/758#issuecomment-414382370