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

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 of pack of utility types for us 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 impressive and thorough, if you want to know more about the improvements Flow did on React, please read it through.

PropTypes can’t be as strict as Flow

A developer from Product Hunt named Radoslave Stankov wrote an article about why they decided to replace PropTypes with Flow. I want 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 here 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 our weight and height. So, here are the rules:

You either pass weight + 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; however, it’s a possible for Flow, thanks to Radoslave Stankov, but it’s a kind of tricky and the error messages are a bit confusing, hopefully this will be improved in the near future.

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 our process 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, you can now.

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 write our component with continuous PropTypes checkup? 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 ask 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.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.