I don't know whether to leave this in or not. The code to support it technically exists, but is unreachable without unstable_ConcurrentMode which we are not defining here.

I removed this to make sure there's no magic any in this.context. That'll only happen when using legacy context; if using modern context it'll be the type of the value prop of this.constructor.contextType.Provider.

Hm, it is strange, cause here https://reactjs.org/docs/context.html#classcontexttype we can see, React allows us to use just this.context, but it is not possible, if context will be deleted from types of Component.

By the way, there is no anything like value in Component.contextType.Provider.

The point is to force the user to declare it themselves because there is nothing better we can do other than any here, and having it already declared would allow people to access it even without a static contextType.

value is the value prop of the Provider exotic component. The actual type of context would be something like typeof this.constructor.contextType extends React.Context<infer T> ? T : never if this.constructor would be useful (its typeof is just Function).

Hm, could you explain, why this code is not working:

class Component<P, S> {
    static contextType: Context<any>;
    ...
    ...
    context: typeof Component.contextType extends Context<infer T> ? T : never
}

Type of context is any always( But it works perfectly in my own component.

That is because, by declaring it in the superclass, you don't have access to its type as assigned in the subclass. The type of the constructor itself is not generic so it just uses the type as declared, assuming Component is constructed as is and not through a subclass. (Note: despite how I phrased it, this still wouldn't work if Component was abstract)

This is the deficiency in TypeScript's class declaration language: it is possible to make an instance type generic, but not the constructor object itself generic.

There is a possible hack with constructible interfaces, though, if they're even accepted in an extends clause. It could be possible to just completely replace the class Component declaration with a pair of interfaces and a const. But... at what cost?.

Thank you for explanation. I agree, what it is ok to get rid of context from typings.

I actually don't know if this is allowed to return null 🤔

Should the argument be of type Error?

I kept it the same type as catch has.

try {
  ...
} catch (e) {
  // e will _always_ be `any`
  // giving it another type is a build error
}

You can also throw anything in javascript; even throw undefined.

I'm not really happy about this. Having an underscored value here looks like reaching into internals; but it's the only way to have access to T in LibraryManagedProps.

An alternative is to make up our own fictional prop name.

I fixed lints that were hit while I was editing this uncommented.

Assuming I'm using $ExpectType correctly these all pass. It just doesn't actually work when the functional/exotic components are used in JSX.

😇

I couldn't figure out how refs work by reading mountLazyComponent in ReactFiberBeginWork.js; I actually thought they didn't work at all at first.

I did verify that they work at runtime, though (refs are set/called when the Suspense resolves).

React will throw at runtime if the Suspense suspends and the fallback is undefined, but null is ok.

Should the argument be of type Error?

Do we need <any> here (and in the few other instances below)?
It looks like ComponentType generic will default to {} anyway, so maybe you could omit it?
See here:

Yeah, if there is no argument it'll be inferred as {} and this will actually cause the compiler to reject subtypes of ComponentType<{}> because {} will be a function or constructor argument's type.

It's the problem of (arg: { foo: string }) => null not being assignable to (arg: {}) => null, but being assignable to (arg: any) => null.

Is this right? If I have a render prop component (where children might be a function), it's not being inferred as functional component.

Implicit children strike back

Again

🙄

I guess I have a New Years break project for a breaking change. Hopefully one I can get to compile.

I'm investigating it further. The problem may not be children, but something else (my current bet is functional components with custom generic types). I'll see if I can come up with a minimum reproduction.

@sandersn @johnnyreilly Would it be possible to condition this breaking change on a specific TypeScript version through typesVersion?

I was thinking of being able to make the change incremental by only updating types on demand, when people update to, say, TS3.3. This would require kind of a "max supported TS version" on types that depend on @types/react.

I'm a bit afraid of it being a python3 problem, though, but the technical debt of @types/react is now nigh-unmanageable.

Yes, I could work around this problem in this specific instance by changing the input to a function instead of FunctionComponent, but it's pervasive and everywhere. A lot of things that currently work in the ecosystem (like function children) work because of ossified bugs in the types, not because of features. @types/react is due for a rewrite.

@diegohaz ah, yes, that is the one big problem with mapped types and infer (and the lack of kinds?); they erase generics and collapse unions. If the props are either of those the output type may be funky.

In another thread we decided it was time to update the types to expect TS 3

Would it be possible to condition this breaking change on a specific TypeScript version through typesVersion?

I'm afraid I haven't played with typesVersion yet and so can't advise. That said, as @ericanderson mentioned there's been prior discussion about upgrading to TS 3. We should do that anyway. If anyone is thinking about submitting a PR that does that then they should expect ♥️ and 🤗