[labs/react] export component and prop types

Which package is this a feature request for?

React (@lit-labs/react)

Description

An explicit helper type for devs to use in JSXIntrinicElements would reduce type conflicts for react clients.

declare namespace JSX {
  interface IntrinsicElements {
    foo: HelperType<CustomElement>;
  }
}

Currently we rely on Typescript to infer what is returned from createComponent and although TS is fairly good, an inference is not as durable as an explicit typing.

Related to: https://github.com/lit/lit/pull/3163

Alternatives and Workarounds

There are a few caveats to keep in mind:

• our package returns a ForwardedRef as a component
• web components not created through createComponent still need proper typing, they are not a ForardRef

Two types should be exported:

1. type returned from createComponent
2. a type any dev can use for IntrinsicElements

[michaelwarren1106]

that’s pretty true. my main use case i guess is with multi-word attributes like display-name. say in my WC, i have a reactive property displayName with an attribute name defined from the Lit decorator as display-name.

In JSX when using a WC tag, say I type the tag name and start typing some attribute <x-foo d. The intellisense would show me displayName:string; right? if I choose that from the context menu, then i’d have <x-foo displayName=“” which wouldn’t be right? In JSX for WCs youve gotta use the actual attribute name, right?

So if the typing isn’t smart enough to know that in JSX displayName should be autocompleted as display-name, then won’t devs who choose to use the autocomplete have to go back and change the autocomplete back to display-name=?

you’re right that the attribute typing would all be strings and booleans, but that’s all JSX can set on a WC tag right now anyway, right? maybe once they land support for setting either/both attrs and props on a WC it’ll get better?

[michaelwarren1106]

So i tested the WebComponentProps type here and I found one error, and had one question.

The error is that class isn’t accounted for. When using a web component as a web component in a react app, you can’t use className, only class will work, right? So that needs to be reflected in the typing, and I don’t see it currently.

The question is “Why can’t the typing be attribute-based instead of property-based?” Right now, when we’re seeing typing messages and autocomplete help bubbles in VSCode, they always contain the JS property names from my WC classes, but not the attribute names. But in react/JSX, only the attribute names work. So something like:

<some-web-component align

would show a typing hint like alignX or alignY instead of align-x and align-y. If the dev uses the autocomplete chooser, they’ll get:

<some-web-component alignY=

and that wont work. A related note is that the type above didnt seem to provide any attribute value hinting when you get the correct attribute. If you type:

<some-web-component align-y="

you dont get any completion help for the values for alignY (‘start’, ‘center’, ‘end’ etc). Presumably thats because the JS prop and the HTML attribute have different names. IMO tho, the typing should reflect that somehow? Does that have to do with what is in HTMLElementTagMap?