The contributing guide as well as the current files use and mention propTypes. Is that going to be our preferred approach or shall we favour Flow types instead?
@satya164 I think you're more eligible to answer that
Flow is certainly superior because it'll provide static type checking and autocompletion. It's also much easier to grasp than prop types in terms of documenting code. It can be used on the CI to prevent unintentional bugs.
However, we shouldn't get rid of PropTypes, because not everyone uses Flow, so runtime warnings will be useful for them.
I think we need to enforce both Flow and PropTypes for now. We should setup CI so that we don't break Flow on master.
However, we shouldn't get rid of PropTypes, because not everyone uses Flow, so runtime warnings will be useful for them.
Wouldn't a babel plugin to rewrite flow types to prop types solve that problem? That way, we could reduce the overheat of keeping two ways of describing the components API in favour of a single source of truth. The problem that I see here is that both of these provide a slightly different syntax for describing things like lists, arrays or optional values and it's rather easy to provide inconsistencies.
Here's a reference implementation: https://github.com/brigand/babel-plugin-flow-react-proptypes
@grabbou I've been thinking about this and I think we'll need to setup a prepublish script which transpiles these flow annotations to propTypes before publishing
Does this need to be open? @satya164
We've not arrived at a conclusion, so yes.
Most helpful comment
@grabbou I've been thinking about this and I think we'll need to setup a prepublish script which transpiles these flow annotations to propTypes before publishing