Flow’s interesting, unfortunately it requires more invasive changes to your code than just prop types. For example, if I remember correctly, you need a declaration for a class component’s state.
We decided to use Flow in a rewrite of an existing React project at work. I found all of the type boilerplate around React/Redux to be somewhat cumbersome at first, but after a few days I didn't even think about it anymore. It feels a little strange writing React code without it at this point.
Same, we're using Flow in for our React Native app but not yet in our older webapp.
I've found more bugs that way that more than offset the extra time spent writing types and being a little bit more verbose to keep flow happy.
The minor annoyances are around the edge cases. Like eslint/flow throws propType errors when using props that were dereferenced from `this.props.someObject`. But you can just write the longer version `this.props.someObject.whatever` and everything's fine.
I mean if you really want to be loose with the type of your component's state, you can just declare its type as Object, eg.
class MyComponent extends React.Component {
state: Object;
constructor(props) {
super(props);
this.state = {
foo: 1, // no type error
};
};
}
Providing a more explicit type for the component's state is a great way to catch bugs, however. It also forces you to more clearly think through which combinations of state properties are valid. Jared Forsyth gave a good talk about this at React Conf: https://www.youtube.com/watch?v=V1po0BT7kac
That's true, but I think that's a very good thing. It can be very useful to define "StateTypes", as well as PropTypes. I think I've caught more than a few bugs by defining types for my state.
