Re: [w3c/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

@prushforth You've missed part of the idea. There isn't multiple inheritance here. Each "component" or "mixin" or whatever we want to call it, can have it's own classification. For example, here it is with two standalone classes, there is no inheriting from multiple things:

```js
class Foo {
  connectedCallback(el) {
    // do something with el
  }
}


class Bar {
  attributeChangedCallback(el, attr, oldValue, newValue) {
    // do something with el's changed attribute
  }
}
```

then

```js
components.define('foo', Foo)
components.define('bar', Bar)
```
```html
<!-- it has "components" associated with it -->
<any-element components="foo bar" />
```

or perhaps

```js
behaviors.define('foo', Foo)
behaviors.define('bar', Bar)
```
```html
<!-- it "has" these behaviors -->
<any-element has="foo bar" />
```

In these examples, `foo` and `bar` are standalone classes, there's no iheritance involved, nothing special. They're just instances that operate on the element using the same familiar Custom-Element life cycle callbacks.

There's no inheritance involved like there is with the current `is=""` attribute.

Also, there are not _completely_ mixins perse, they aren't being mixed onto a single class (that _does_ involve inheritance). These behaviors don't involve inheritance, they aren't mixed into a class, they are simply classes that each operate on the element.

They might be _similar_ to mixins, in the sense that they can both modify the same element and conflict with each other in that regard, which can be a problem similar the problem of multiple mixins trying to operate on the same `this` and conflicting with each other.

In this case, each component/mixin/behavior has its own `this`, and each mixin won't conflict with anything it may do on its `this`. There may only be conflicts when they try to modify the same properties on the target element, for example.

To mitigate this, [I proposed](https://github.com/w3c/webcomponents/issues/662#issuecomment-327369316) that, given an element, there can be a simple way to get a component/behavior instance from the element. At the cost of a little extra verbosity, it would allow a component/behavior author to expose public APIs on the component/behavior instance rather than on the target element, and then an end user would be able to easily get the component/behavior from the element to be able to use the public API.

If components/behaviors are well documented, they can perhaps add public APIs onto the target elements directly. If there's a conflict, it would be the app author's job to know how the components/behaviors work and to identity which components/behaviors conflict with each other and to act accordingly (this is true for anyone who uses mixins in any form, but in this case there's less chance for conflicts if each component/behavior uses its `this` rather than the target element).

-- 
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/509#issuecomment-327910080