[TS] breaking change in 0.11: ShadowRoot object is no longer assignable to second parameter of render() function

[trusktr]

The web component example now fails in TypeScript in 0.11:

    !this.shadowRoot && this.attachShadow({mode: 'open'});
    this.dispose = render(this.render.bind(this), this.shadowRoot!); // ERROR

The error is:

Argument of type 'ShadowRoot' is not assignable to parameter of type 'HTMLElement'.
  Type 'ShadowRoot' is missing the following properties from type 'HTMLElement': accessKey, accessKeyLabel, autocapitalize, dir, and 177 more.

In version 0.10, the type of the second parameter was Node, which a shadowRoot is assignable to.

[ryansolid]

Nice find.. thanks I actually had to fix this for the Preact version of my Web Component library. I will get this fixed up tonight.

[trusktr]

Just curious, is this released yet? I ran npm install solid-js last night on a new project and got the same error.

EDIT, well not the exact same error, but an error that complained that a Node is not assignable to MountableElement.

The reason the thing I'm passing into render is typed as Node, is because that's a common class between elements and shadow roots so I typed it as Node.

[trusktr]

I see what MountableElement is trying to do. Node is not in that list, because it can't be mounted. It is more of an abstract base class.

Current MountableElement is Element | Document | ShadowRoot | DocumentFragment, but maybe that needs to be updated actually. Element is an abstract base class too. Maybe it should be HTMLDivElement | HTMLInputElement | ... | SVGSVGElement | ... | Document | ShadowRoot | DocumentFragment to captute only the actually-mountable elements.

But if it will be Element | Document | ShadowRoot | DocumentFragment, where Element is not actually mountable, then maybe the type should just be Node, and let runtime errors otherwise handle the case that someone tries to mount to a Node (which is impossible to do anyways).

[ryansolid]

Yeah I debated this. I just copied Preacts types here. I do think more general is probably better, but mostly since I don't care about type specificity that much. Although I'm not sure how much this would be hit. I have no issue adding this to the types when I'm in there next.

[trusktr]

Made a PR: #124