In the second block of examples, are N1 and N2 missing x: string in the commented result?

jwbay Yes, thanks. Now fixed.

Anders Hejlsberg (@ahejlsberg)

I'm not 100% sure but it seems like this change breaks a common pattern I use (and probably others, at least in the future) with React. This worked in yesterday's nightly build:

export class MyComponent extends React.Component<{ someValue: number }, {}> {
	shouldComponentUpdate(nextProps: this["props"], nextState: this["state"]) {
		if (nextProps.someValue > 0) {
			// ...
		}
	}
}

But now errors:

// Error: Property 'someValue' does not exist on type 'this["props"]'.'

The problem might be related to the fact that this["props"] has the type:

{
    children?: React.ReactNode;
} & {
    someValue: number;
}

I've tried to work around this by using typeof this.props instead but that didn't seem to help:

export class MyComponent extends React.Component<{ someValue: number }, {}> {
	shouldComponentUpdate(nextProps: typeof this.props, nextState: typeof this.state) {
		if (nextProps.someValue > 0) {
			// ...
		}
	}
}

// Error on 'typeof this.props': Identifier expected

The relevant ambient declaration for React.Component looks like:

    // Base component for plain JS classes
    class Component<P, S> implements ComponentLifecycle<P, S> {
        constructor(props?: P, context?: any);
        constructor(...args: any[]);
        // ...
        props: { children?: ReactNode } & P;
        state: S;
        // ...
    }

Rotem Dan (@rotemdan) Yes, there was a minor typo that's causing this issue. I will have a fix shortly.

Thanks, I temporarily worked around these errors by creating a type alias for this[props], which was relatively easy. I'm intentionally using the latest nightly builds with a large code base to try to help to quickly identify issues of this kind. If I update every day it makes it easy to speculate what could have been the cause by looking at the commits of the previous day.

Anders Hejlsberg (@ahejlsberg) this is just CRAZY!

I can now build a decorator, export it as const and export a type with the same name.
The type is a Record of a name and the decorators expected signature... I now have a dynamic typed decorator, perfect for lifescycle hooks as decorators.

export class Class implements MyDecorator<'myMethod'> {
  @MyDecorator()
  myMethod() { // myMethod's signature is fixed, if changed -> type error! if name changes -> type error
  }
}

This is getting to be the best type system ever, I am really amazed! thank you guys!

It would be very nice if a class decorator could "replace" the original class type with respect to the type system so that we could use such a decorator to fully implement a mixin, both the implementation at runtime and the extended type for compile time.

Forgive me if it's a silly question, but would this change help at all with what I'm looking for here?

Brand new to TS here. Is there a simple way to make this work?

function Foo() {}

class Bar extends Foo {
    constructor() {
        super()
        console.log('Bar!')
    }
}

new Bar

A class needs to inherit from something that has a "construct signature"; i.e. a declaration of what the shape of the object it returns if called with new. a function does not have that.

if this is your function, i would suggest switching it to a class, and switching this.prop assignments in it to property declarations.

if this is a function you got from a different module, then consider declaring it as a calss, e.g. declare class Foo {}.

you can always cast the type to a constructable type, e.g. const Foo: { new (): FooInstance } = <any>function Foo() { }

if this is your function, i would suggest switching it to a class
if this is a function you got from a different module, then consider declaring it as a calss

In reality it is a dynamically generated class as in the following (working) cases:

class Foo extends multiple(One, Two, Three) {}

class Foo extends MixinOne(MixinTwo(Three)) {}

I am relying on those features to do interesting things. These type of things are possible in JS.

Can I use interfaces somehow?

Oh, another thing. I know how to declare a type, for example, so that I can extend from a Backbone.View, by declaring the class definition.

But how do I declare that some function returns a specific class?

F.e.,

// Third party
function get(){
  return Backbone.View
}

// My file
Class Foo extends get() {}

Joe Pea (@trusktr) you need #4890, this should land in the next few days.

Mohamed Hegazy (@mhegazy) Once released, how would I write that last example? Is the following correct?

interface Constructable<T> {
    new (...args): T;
}

// Third party
function get(): Constructable<Backbone.View> {
  return Backbone.View
}

// My file
Class Foo extends get() {}

What about the following?

function multiple(...classes: whatGoesHere?): Constructable<whatGoesHere?> {
  // uses Proxy
}

class Foo extends multiple(One, Two, Three) {}

Please see #13743

Does this also allow extending from typeof expressions?