We cannot type the static setup automatically, we can't even infer the type of setup(props, ctx) automatically, that's my main point against static setup, other point is #276

The reason to keep as Class CompositionAPI instead of full class support is because this should be a simple implementation to fix a limitation, as shown in the RFC this could be only used to type the render template or to build components. For full class support I would still recommend Vue Component Class

To have the JSX/TSX working we only really need an constructor with {$props}

interface MyCustomComponent<P> {
  new (): {
    $props: P
  }
}

declare const Comp: MyCustomComponent<{ /* props */}>

;<Comp />

Altho this does not extend DefineComponent which currently might cause a few issues

The solution to not spam with the this keyword could be the use of the with statement.

The solution to not spam with the this keyword could be the use of the with statement.

You wouldn't be needing to spam this

setup(){
 const {props, context} = this;
 // ...
}

I think that this proposal should be thought with the native class syntax first and then for TypeScript.

Some complex features/specs may be achieved with decorators.

The reason why this is thought as typescript first:

• There's Vue class component for that.
• This is a solution for a problem that cannot be achieved by doing options object.
• Where's why Vue Class was dropped in the first place

This Vue Class Composition is not meant to be Vue Class API as it mention on the "Detailed Design":

API is kept simple and is not a replacement of Vue Class Component, this Vue Class Composition is meant to only support composition-api, options API are not meant to be supported

I have no strong feeling about the implementation details or syntax, my only concern is the one expressed in the RFC - yet another way to author components.

I feel the same way, this is basically the only way to have this behaviour (except of { new<T>(): { props: T} })

If this does end up getting accepted, is there any reason not to just support a kind of class component API in core that will entirely replace Vue Class Component? At least that way there would be just one way to author component with classes - I imagine it would be very confuing to see both a class syntax in core, as well as an official library.

Edit: I read the Class RFC in more detail, seems there are still some compelling reasons not to have a fully fledged class API in core.

Having both might be a bit confusing, alternatively we can have a purely type way vuejs/core#3682 .

My goal is simple, I want to be able to infer generic types when I'm passing props on the template and be able to do change some Generics types. Composition-API and Options-API simply cannot support this, because they are an object and by definition they have already the types fully resolved.

The only way we currently have to support this is the Functional Component, the current defineComponent does not support this well currently (which we should be able to fix), but it's a Functional Component and very limited in terms of using composition-api or other.

I agree having strongly typed templates (events, etc) is highly desirable and something we probably do need to have a similar DX to React and Angular. Having it work with generics would be very neat.

This is the challenge - assuming everyone wants to have a better DX (assumptions are never good, but for the sake of discussion) it would mean this should be the way to define components. It feels a bit bad for the main/recommended way to define a component not to be the "best" way (in terms of objective things, like type safety and IDE support).

assuming everyone wants to have a better DX

Better DX is not free in this case, I see this being used on component libraries and on components where the type is important to dictate other prop types, but this comes at cost of defining class API and being stuck to Composition-API, altho I see Vue Class Component taking advantage of this and be able to also do the generic types support.

It feels a bit bad for the main/recommended way to define a component not to be the "best" way (in terms of objective things, like type safety and IDE support).

You can still have type safety and IDE support with VOA and VCA, you just missing generic types and being able to infer the correct generic, see vuejs/core#3102, on that issue as soon as you extract the prop type the Clearable generic will be converted to boolean making the onChange losing it's conditional type.

Further progress is being done #436 , it took some ideas from here, supporting Class API is not something we are too keen on (because we already have the plugin and it would add another way to do things)

EDIT: Since the whole point of the RFC API is to allow generic components