React 16.6 was released today: https://reactjs.org/blog/2018/10/23/react-v-16-6.html
I would have made this as a PR, but there is a problem with the new static contextType feature that I don't know how to solve. This is probably a TypeScript core problem.
First, the type of context is defined in class Component and marked as @deprecated (which triggers the deprecation tslint rule), but context is only deprecated if static contextType is not defined.
Second, the type of this.context depends on the type of static contextType, and there is no way I can think of, within TypeScript's generic system, declaring that in the types. While I can hack that into ComponentClass's definition, it wouldn't help actually subclassing Component correctly.
Probably the only solution that would work short term is removing the context: any declaration entirely, but it'd be a breaking change.
This is not the first time we hit limitations of the generic system in React; see getDerivedStateFromProps which had to be left out of Component's definition entirely because it'd just have to have any inputs and outputs anyway.
React 16.6 was released today: https://reactjs.org/blog/2018/10/23/react-v-16-6.html
I would have made this as a PR, but there is a problem with the new
static contextTypefeature that I don't know how to solve. This is probably a TypeScript core problem.First, the type of
contextis defined inclass Componentand marked as@deprecated(which triggers thedeprecationtslint rule), butcontextis only deprecated ifstatic contextTypeis not defined.Second, the type of
this.contextdepends on the type ofstatic contextType, and there is no way I can think of, within TypeScript's generic system, declaring that in the types. While I can hack that intoComponentClass's definition, it wouldn't help actually subclassingComponentcorrectly.Probably the only solution that would work short term is removing the
context: anydeclaration entirely, but it'd be a breaking change.This is not the first time we hit limitations of the generic system in React; see
getDerivedStateFromPropswhich had to be left out ofComponent's definition entirely because it'd just have to haveanyinputs and outputs anyway.