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

`needsInternals` sounds like a sound solution if it's passed as an option to `customElements.define`, but I guess it leaves two issues, that it's annoying to have to mention this in two places, and the difficulty of working with subclasses.

Here's a slightly different possibility, as an analogue of [this decorator-based solution](https://github.com/tc39/ecma262/issues/1341#issuecomment-435593024) ?

```js
// In the browser
customElements.getAttachInternals = function(klass) {
  if (klass is already registered as a custom element) throw new TypeError;
  return function(element) {
    // Possibly generalize this check to make working with subclasses better
    if (element's custom element definition's constructor !== klass) throw new TypeError;
    return element.[[Internals]];
  };
}

// Usage example
class MyElement extends HTMLElement {
  #internals = attachInternals(this);
}
let attachInternals = customElements.getAttachInternals(MyElement);
customElements.define('my-el', MyElement);
```

By requiring that `getAttachInternals` be called before `customElements.define`, the system ensures that this call is collaborating with the code which defines the element (if custom element classes don't sit around un-defined for long). You could later make `getAttachInternals`be overloaded as a decorator, to save a little bit of code, but no need to block on that.

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