It’s time to drop PropTypes and just use Flow for React

3 min readSep 14, 2017

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.