We were kind of encouraged to use PropTypes
from the beginning since we started learning React
, and it actually does a great type-checking job so far.
However, based on several reasons I’ve decided to retire PropTypes
from our projects:
Flow now has better support for React and React Native
Flow 0.53+ made a bunch of improvements to better work with React Components. In previous versions of Flow, we have to pull lots of strings just to make it work with React
.
In the new Flow
, they provide us a pack of utility types to have a better type-checking upon React Components
. To name a few:React.Node
, React.StatelessFunctionalComponent<Props>
,React.ChildrenArray<T>
, and all. The article wrote by Caleb Meredith was indeed impressive and thorough, if you keen to know more about the improvements Flow did for React, please read it through.
PropTypes can’t be as strict as Flow
A developer at Product Hunt
named Radoslave Stankov
wrote an article about why they decided to replace PropTypes
with Flow
. I’d like to point out one of those arguments here because I think it’s one of the main reasons that we should just do the same. I’m gonna tweak a bit of his example to make a point:
Say you have a User
component which needs a person’s BMI, and we know that we can calculate the BMI from weight and height. Here is the rule:
You either passweight + height
or BMI
to the component, but never both. And this means the following cases should all be warned.
<User weight={80} height={180} BMI={24.7} />
<User height={180} BMI={24.7} />
<User weight={80} />
However, PropTypes
is not able to pull off something like this. But it’s possible for Flow
, a bit tricky though:
type Props = {
weight: number,
height: number,
BMI?: void,
} | {
BMI: number,
weight?: void,
height?: void,
};
This example is pretty self-explanatory. The point is, it’s possible using Flow
, thanks to Radoslave Stankov.
However, it’s a kind of tricky and the error messages are a bit confusing, hopefully this will be improved soon.
Speed up the development
Since PropTypes
check our props in runtime, so if we drop it, it will definitely speed up the recompiling process. As Flow
is a static type checking tool, it won’t affect as much.
Work way better with your IDE/editors
Let’s face it, you can’t do much about PropTypes
with your favorite IDEs. But with Flow
, it’s like a breeze.
If you are a vim user, you can use vim-flow; if you are a GUI editor user, say VSCode, you will have much fancier support:
Params hinting
JSX hinting
Remember the days that we need to write our component with continuous PropTypes
checkups? Not anymore:
Error hinting
Small improvement on the bundle size
There’s been some discussions about stripping the PropTypes
in production. And actually there’s already a babel-plugin-optimize doing this for us. So if we drop PropTypes
, we can also gain some performance from the reduction of bundle size.
Downside
IMO, Flow
has done a pretty awesome job, except some of their error messages are really confusing. However, the Flow
team is already onto it. They even asked people on twitter about it.
If you encounter any error messages that confuse you, feel free to file an issue, or even better, help them with a PR.
Conclusion
To be honest, if you are still rusty about Flow
, you can use both of them on your projects first. When you are confident with your skills of Flow
, you can then drop the PropTypes
once and for all.
Thanks to TaopaiC Tao to discuss & review this article for me.
Special thanks to Stagfoo to review the grammar for me.