JSX types should automatically pick setter types instead of getter types.

[trusktr]

🔍 Search Terms

"typescript github jsx setter type"

Related:

• https://github.com/microsoft/TypeScript/issues/60162

(however that issue is for mapped types in general, while this one is for fixing how TypeScript's internal mechanism reads types passed into JSX (UppercaseComponents) or JSX.IntrinsicElements)

✅ Viability Checklist

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When using a class definition for a JSX type, the JSX prop types will type check against the getter, not the setter of a class property.

📃 Motivating Example

Although JSX can require or not require certain values, JSX is effectively a language feature for passing or setting values.

They should be treated mode like optional parameters ? is specified, and should otherwise look at setter types to achieve the semantics they truly align with.

Here's an example:

class MyClass {
  get foo(): number {...}
  set foo(value: string | number) {...}
}

function Component() {
  // This is valid:
  return <MyClass foo={"123"} /> // TYPE ERROR ("string not assignable to number")
}

We get a type error, but "123" is a valid value because the foo setter accepts string values based on its type definition.

But this is the crux: we're not getting the class value, we're setting it, for all intents and purposes. It doesn't matter if under the hood we're actually creating a vdom object, as that is merely an implementation detail, while the language itself is really determing other use cases:

• we're passing values to a function
• we're setting values on an object
• we're assigning values onto an object

As an example, this is especially true with Custom Elements, in situations like this,

return <some-custom-element someProp={123} />

where we are setting a property on the DOM element instance.

The problem is that TypeScript is type checking JSX props based on the getter type of a property, but in fact they are effectively setters that are meant to pass values to their destination, the user is not getting a value from the JSX.

An example Custom Element definition:

class SomeEl extends HTMLElement {
  #someProp = 123 // type is 'number'

  // returns 'number'
  get someProp() { return this.#someProp }

  // accepts 'string | number'
  set someProp(val: string | number) { this.#someProp = Number(val) }
}

customElements.define('some-custom-element', SomeEl)

To represent this, TypeScript needs to effectively treat JSX props as similar to function parameters instead of as an object type, allowing some "parameters" to be optional, and preferring setter types when those exist.

It is possible someone will assign SomeEl into JSX.IntrinsicElements for JSX type checking,

declare module 'some-jsx-framework' {
  namespace JSX {
    interface IntrinsicElements {
      'some-custom-element': SomeEl
    }
  }
}

so the system would need to take in the object/class type, and map that to its internal handling of JSX which would be more like parameter, having preferred any setter types when they exist.

This playground example show a type error for a valid value.

💻 Use Cases

1. This will improve JSX type definitions.
2. Current approaches are limited to getter types, and JSX cannot fully represent desired types.
3. Workarounds include declaring fake properties with conventional syntax such as __jsx__foo: string | number from which a mapped type can map to a JSX type definition. Example:

   const MyClass = class MyClass {
     get foo(): number {...}
     set foo(value: string | number) {...}
     /** End users: do not use this, this is for JSX types only. */
     __jsx__foo: string | number
   }
   
   // This is a special mapped type that maps `__jsx__*` properties for JSX types.
   type MyClass = MySpecialMappedType<typeof MyClass>
   
   function Component() {
     return <MyClass foo={"123"} /> // fixed
   }
   

   TypeScript playground example (same example from #60162)

The workaround in point 3 is cumbersome, but that is the only way.

The idea in https://github.com/microsoft/TypeScript/issues/60162 would help make the mapped type workaround simpler, but would not solve the actual JSX issue.

[trusktr]

It is also the case that mapped types get further in the way. For example, we actually may want to do this:

declare module 'some-jsx-framework' {
  namespace JSX {
    interface IntrinsicElements {
      'some-custom-element': Pick<SomeEl, 'foo' | 'etc'>
    }
  }
}

as we do not want all element methods to be JSX props. For example, we don't want to let the user think this can do this,

return <some-custom-element querySelector={selector => {...}} />

so we use Pick<SomeEl, 'foo' | 'etc'>, but this has the side-effect of selecting getter types (#60162).

So we have two issues:

• mapped types using getters (https://github.com/microsoft/TypeScript/issues/60162)
• and JSX using getters (this issue)

Not sure what the solution is for the direct-to-JSX types (the example in the OP without using Pick), but if there were something like PickWithSetters<obj, 'foo' | 'etc'> that would certainly help.