New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
prasannavl opened this Issue Apr 16, 2016 · 4 comments

Comments

Projects
None yet
5 participants
@prasannavl

prasannavl commented Apr 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Apr 16, 2016

Member

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.

Member

gaearon commented Apr 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jimfb

jimfb Apr 16, 2016

Contributor

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.

Contributor

jimfb commented Apr 16, 2016

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.

@jimfb jimfb closed this Apr 16, 2016

@jamesgpearce

This comment has been minimized.

Show comment
Hide comment
@jamesgpearce

jamesgpearce Jun 11, 2016

Member

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)

Member

jamesgpearce commented Jun 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Jun 11, 2016

Member

@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.

Member

sebmarkbage commented Jun 11, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment