Allow `this` in constructor parameter

[hediet]

Search Terms

type, this, constructor, TS2526

Suggestion

Currently, this code fails with A 'this' type is available only in a non-static member of a class or interface.ts(2526):

class MyClass {
    private props: { baz: string };
    constructor(props: this["props"]) {
       this.props = props;
    }
}

It would be awesome if this could be supported in constructor arguments.

Use Cases

This is very useful for react components, as demonstrated in the following example.
More general, sometimes a class extends a generic base class which requires generic data for initialization. If the super class also wants to do some initialization, it needs to pass this generic argument down to its base class. As constructor arguments must be typed, the type of this generic argument must be explicitly stated in the super class.
In those cases, it is very practical to use this to refer to a field of that base class that has the right type.

Examples

class MyComponent extends React.Component<{
    title: string;
}> {
    constructor(props: this["props"]) {
       super(props);
       // ...
    }
}

Current Workarounds

class MyComponent extends React.Component<{
    title: string;
}> {
    constructor(props: MyComponent["props"]) {
       super(props);
       // ...
    }
}

This only works if the base class declares a static props member.
Also, it has the downside that you must write out the name of the current class. This obfuscates the fact that it refers itself.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[dl748]

This has so many problems. There is already a correct way to do this. And IMO this is very ugly code to look at, at least use "this.props" or "MyComponent.props".

[hediet]

@dl748 What problems does this have? What is the correct way to do this? How would you use this.props? Note that this["props"] is used as type here. You can only use this.props in a type expression when using typeof.

[dl748]

This has a very narrow use case, in that it depends on the calling code (where new is called) not caring about types (e.g. like React). It forces any serious calling code to become typeless, which defeats the purpose of using typescript.

The correct way to do this is to use a named type

type PropsType = {
  baz: string
}
// or
interface PropsType {
  baz: string
}

class MyClass {
  private props: PropsType
  constructor(props: PropsType) {
    this.props = props
  }
}

class MyComponent extends React.Component<PropsType> {
  constructor(props: PropsType) {
    super(props)
    // ...
  }
}

This allows for the type to be exported or reused.

class Reuse {
  private t: any; // what type is this?
  public test() {
    const c = new MyClass(t as any); // t would have to be any or typecasted as any to be used
  }
}

The only real way for a developer to use this is to go into the definition file for MyClass and copy and paste the type into the variable they will use. This is far more ugly to use.

And while, yes, you can do constructor(props: { baz: string }) which has the same problem. This is just because it should be allowed, at least as a general rule for function definitions, but it's considered bad design practice to put this on public functions (i.e. library or class).

After the type is named, there are many nifty things we can do with it.

As far as this["props"] vs typeof this.props, at least i feel that the later is far more describing of what is happening. It "looks" cleaner. When looking at this["props"] i need to do 2 tests in my head, is it succeeding a colon, and if so, is this in a object or is it a type definition. You should allow both, if possible.

[RyanCavanaugh]

The use of this["props"] over MyClass["props"] seems very marginal - it basically only helps you when there even is a derived class and the derived class doesn't write its own constructor, which doesn't seem terribly likely in practice.

[hediet]

Besides semantical differences between this["props"] and MyClass["props"], I already prefer the use of this over MyClass as it clearly refers to the current class, whereas MyClass only refers to the current class if the current class is named MyClass. The uniform usage of this across multiple classes makes mental patten matching much easier, compared to the use of their individual class names. Also, this is just much more convenient to type and to remember.

@dl748 I usually try to minimize the number of named symbols. It helps auto import and reduces the amount of things you need to remember or rename. This is why I prefer MyComponent["props"] over MyComponentProps. In practice, components get renamed while their props types are forgotten. This cannot happen if you use MyComponent["props"].

However, I can understand if my arguments for allowing this in constructors don't really apply as they favor this over MyClass for the wrong reasons.

[kuba-orlik]

it basically only helps you when there even is a derived class and the derived class doesn't write its own constructor, which doesn't seem terribly likely in practice.

This is exactly my use case and I'd love if this was possible in TypeScript :)

[dl748]

@dl748 I usually try to minimize the number of named symbols. It helps auto import and reduces the amount of things you need to remember or rename. This is why I prefer MyComponent["props"] over MyComponentProps. In practice, components get renamed while their props types are forgotten. This cannot happen if you use MyComponent["props"].

Except this would basically only works with React, its pretty worthless for everyone else. I think a feature that only works with a specific framework is very poor.

This sounds better as a react specific plugin, than should be built into the language.

[kuba-orlik]

I don't think this use-case is React-specific. In my opinion this use-case is useful whenever creating a framework in general.

I'm transitioning our in-house framework to React and this feature would make the development much easier. We have a class of field types of a collection and each field can take some parameters that customize the behavior. It makes sense to take those parameters in the constructor. But the main abstract Field class does not now yet what shape those parameters need to be. So we have to create a new constructor for each subclass that just calls the super function... That's not pretty :)

[lkster]

+1

I need to get type of class that inherits some base class there. Like:

class BaseClass {
    public constructor(arg1: typeof this) {}
}

class ChildClass extends BaseClass {}

// so in the end this will work
new ChildClass(ChildClass)

// but this won't as with any other class that extends BaseClass
new ChildClass(BaseClass)

And as I could achieve that with generics like

class BaseClass<T> {
    public constructor(arg1: typeof T) {}
}

class ChildClass extends BaseClass<ChildClass> {}

It makes more problems if I need to extend ChildClass. The solution right now is:

class ChildClass<T = ChildClass<any>> extends BaseClass<T> {}
class GrandChildClass extends ChildClass<GrandChildClass> {}

This obviously doesn't look great

[jcalz]

Related to #5863?

[Pauan]

@RyanCavanaugh I am speaking as a representative of amCharts.

We use this pattern a lot in our code:

export interface IFoo {
    ...
}

export class Foo {
    declare public _properties: IFoo;
 
    constructor(properties: Foo["_properties"]) {
        ...
    }
}

We use this pattern in order to simulate associated types.

We would really like to use this["_properties"], because we often do have classes which inherit from the parent and don't have a constructor of their own. Right now we have to manually create dozens of useless dummy constructors:

export interface IBar extends IFoo {
    ...
}

export class Bar extends Foo {
    declare _properties: IBar;

    constructor(properties: Bar["_properties"]) {
        super(properties);
    }
}

Since all normal methods can use this, why shouldn't constructor also allow it? It's a very bizarre exception that seems to serve no purpose.

---

@dl748 That is incorrect. It has been possible for a long time to use this and this["foo"] in all normal methods. They are not a new feature, and we use them very extensively in our code (which does not use React). They are incredibly useful and not framework specific at all.