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

> ehr ... like what?

...

>  similar to observed attributes

...which I will expand on after addressing a few things.

> Let's not make this impossible for everyone to achieve in less than year, maybe?

Decorators imply that, however, decorators are just functions and always have been; this part of the API isn't contentious and is the part I wanted to focus on.

> Decorators are Stage 2 and not even close to be shipped.

Which I explicitly noted by also saying:

> It'd be nice if decorators were further along in TC39 because they're a perfect fit for this in JS land. 

I'll try and flesh this out a bit more. I think we're suggesting very similar things, but I'm trying to cut back the API a little bit.

### JS

As stated above, decorators are just functions. These are the same thing:

```js
function withFormParticipation (Base) {
  // ...
}

@withFormParticipation
class MyElement extends HTMLElement {}

// is the same thing as...

const MyElement = withFormParticipation(class extends HTMLElement {});
```

Decorators can be composed:

```js
function likeFormElement (Base) {
  return withFormAccessibility(withFormParticipation(Base));
}

@likeFormElement
class MyFormElement extends HTMLElement {}

// or, of course...

const MyFormElement = likeFormElement(class extends HTMLElement {});
```

You go on to say:

> I'd rather be pragmatic and move the Web forward, specially because any procedural way can be easily extended later on through decorators. That's the whole point, giving us the ability to simplify otherwise cumbersome low-level patterns, which is why we all wrapped CustomElements API somehow, right?

I was never against this, in fact, if you read in to my suggestion, I'm espousing the lowest-level way of doing this: functions. Decorators at this point are not worth their weight alone, but worth discussing as they emphasise functions as the composition mechanism, and are a future feature of ES that we'd be able to leverage if following this path.

### CSS, but also JS sugar

This is where the likening to `observedAttributes` comes in. Instead of adding `behaviours` as an option to the third argument of `customElements.define()`, there already exists the convention of adding information like this to the constructor. The third argument only exists for `extends` anyways, which is what we're trying to propose alternatives to. Orthogonal to this, I see no reason why extends wasn't specified as a static member in the first place. Anyways.

If `behaviours` were added as a static member, subclasses would automatically inherit them, which is what I'd expect to happen when extending something that has specific behaviour. If we pass it as the third argument, this doesn't happen explicitly, if at all.

```js
customElements.defineBehaviour('like-form-element', [
  withFormAccessibility,
  withFormParticipation
]);

class MyFormElement extends HTMLElement {
  static get behaviours () {
    return ['like-form-element'];
  }
}

// This automatically behaves like-form-element because of the prop.
class MyFormElementSubclass extends MyFormElement {
  // ...
}
```

Really, the `static behaviours` property and `defineBehaviour` is syntactic sugar for having to compose them manually, and serves as a stop-gap for decorators, for the time being. I think it's worth touching on this point to ensure we don't pigeonhole ourselves, however, not I'm convinced we should spend too much time on it. Shipping the JS part is of utmost importance. I think it would be pragmatic to leave CSS alone for now and to see how libraries handle it.


-- 
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-281202515