React: React ContextTypes, PropTypes when using an already static typed language like TypeScript

[prasannavl]

The ContextTypes, and PropTypes that have to set for validation are a fine concept. But when already using a language like typescript which takes care of the typing, it is extremely redundant and painful to have to keep updating the ContextTypes in particular.

PropTypes, however are alteast optional, but ContextTypes aren't. Please provide an option to make them optional so that when using languages that provide static typing on top js, the pointless redundancy can be eliminated.

[gaearon]

Thank you for the feedback!

The context API is an experimental feature, and its API is definitely a work in progress. As React phases PropTypes out in favor of static analysis (Facebook mostly uses Flow for this), I expect that the context API will also stop relying on PropTypes. However I don’t think we plan to change it in the near future; at least not until we’re confident how we want to change the context.

[jimfb]

Context types is not likely to become optional in the near/foreseeable future, although I suppose anything could change. There are several reasons we would want to keep contexttypes. Most of them revolve around the fact that proptypes are implicit, and thus much harder to reason about than props which are easy to see and passed explicitly. Some reasons are: readability, documentation, and correctness (context types are implicit and can have name conflicts, making them much more error prone, and the types can't be verified at compile time even by a language like typescript). But the most important reason of all... is because it opens the door to some internal optimizations... Specifically, it is helpful to know which context variables a component is listening to because this allows us to know which components may need to be re-rendered when a variable changes.

If you are using typescript and don't want to jump through the hoops of specifying the types of your context variables, you can specify all of them as React.PropTypes.any, which will match anything. Then you're effectively just specifying the name of the contexttype, which is the minimum information React needs at runtime.

[jamesgpearce]

At the very least it's sad that you have to declare childContextTypes to get context to work at all. (Surely the presence of getChildContext could be sufficient clue)

[sebmarkbage]

@jamesgpearce We don't know what the child will read so that would mean rerendering anything that reads any context when anything changes. Instead of _only_ rerendering for specific keys. It would probably need something to indicate specificity. E.g. Component.contextTag = someSymbol.

In the original diff it seemed to make sense to reuse PropTypes for this purpose.

Note that none of the static type systems have any way to check the context type. So providing a dynamic type is actually quite helpful to track down type error bugs even if you use a static type system.

Anyway. We don't really know how to make context efficient anyway so it is likely its use cases will be split up and addressed with other APIs going forward. It is highly recommended that you use higher order components if you're using it as a power user feature.