102

PropTypes and Flow cover similar things but are using different approaches. PropTypes can give you warnings during runtime, which can be helpful to quickly find malformed responses coming from a server, etc. However, Flow seems to be the future and with concepts like generics is a very flexible solution. Also the autocompletion offered by Nuclide is a big plus for Flow.

My question now is which is the best way to go, when starting a new project. Or could it be a good solution to use both, Flow and PropTypes? The problem with using both is that you write a lot of duplicate code. This is an example of a music player app I wrote:

export const PlaylistPropType = PropTypes.shape({
    next: ItemPropTypes,
    current: ItemPropTypes,
    history: PropTypes.arrayOf(ItemPropTypes).isRequired
});

export type Playlist = {
    next: Item,
    current: Item,
    history: Array<Item>
};

Both definitions basically contain the same information and when the data type is changed, both definitions need to be updated.

I found this babel plugin to convert type declarations to PropTypes, which might be a solution.

machineghost
  • 28,573
  • 26
  • 128
  • 197
danielbuechele
  • 2,974
  • 2
  • 15
  • 28
  • 2
    If you want to get started with Flow try this post: http://www.robinwieruch.de/the-soundcloud-client-in-react-redux-flow/ – Robin Wieruch Jul 10 '16 at 09:47
  • 2
    From experience, using the plugin mentioned in the question is not a very good idea. It doesn't support all types of components, is entirely broken with React Native as of v0.39, and is generally very fragile. The owner of the repo used to respond to these issues fairly quickly, but it seems he's lost interest and can no longer be relied upon to maintain it. – Tomty Mar 01 '17 at 17:24
  • Try tcomb [via](https://github.com/gcanti/babel-plugin-tcomb) Babel plugin for static and runtime type checking using Flow and tcomb. – comerc Apr 15 '17 at 10:49

4 Answers4

83

One year after asking this question, I wanted to give an update about how my experiences with this problem.

As Flow evolved a lot, I started typing my codebase with it and did not add any new PropType definitions. So far, I think this is good way to go, because as mentioned above, it allows you to not only type props but other parts of your code, too. This comes in really handy for example when you have a copy of you props in the state, that can be modified by the user. Also, auto-completion in IDEs is an awesome gain.

Automatic converters in one or the other direction didn't really take off. So, for new projects, I would now really recommend using Flow over PropTypes (in case you don't want to do the typing twice).

Prince Odame
  • 462
  • 7
  • 14
danielbuechele
  • 2,974
  • 2
  • 15
  • 28
36

Other than both belonging to the very wide field of type checking, there's not really much similarity between the two.

Flow is a static analysis tool which uses a superset of the language, allowing you to add type annotations to all of your code and catch an entire class of bugs at compile time.

PropTypes is a basic type checker which has been patched onto React. It can't check anything other than the types of the props being passed to a given component.

If you want more flexible typechecking for your entire project then Flow/TypeScript are appropriate choices. So long as you are only passing annotated types into components, you won't need PropTypes.

If you just want to check prop types, then don't over-complicate the rest of your codebase and go with the simpler option.

Dan Prince
  • 27,111
  • 12
  • 81
  • 112
  • 12
    Yeah, they are very different in terms of how they work. However, the purpose of using them is very similar, I think. But one thing you pointed out is a good point: Flow let's you cover more of your codebase, whereas you are limited to props when using PropTypes. – danielbuechele Mar 17 '16 at 15:53
  • 3
    The purpose of use is only very similar if you _only_ use Flow to check prop types. One is basically a language, the other is a barely a library. – Dan Prince Mar 17 '16 at 17:02
  • Totally agree with @DanPrince. And I don't think this is a good idea to check for malformed responses from server with PropTypes. It is better if you have manual checks for this and your UI responds properly (displays a warning message for example) instead of just throwing a warning into the console. – Yan Takushevich Jan 16 '17 at 13:29
  • 7
    @YanTakushevich You need to do both. PropTypes should be disabled during production anyway, so you always need manual checks to make sure that your users have a good experience. However, PropTypes can be very useful for run-time warnings during development. It's just a nice safety net to make sure you don't forget anything. – ndbroadbent Feb 23 '17 at 11:25
29

I believe the missed point here is that Flow is a static checker while PropTypes is a runtime checker, which means

  • Flow can intercept errors upstream while coding : it can theoretically miss some errors that you wont know about (if you didn't implemented flow enough in your project for example, or in case of deep nested objects)
  • PropTypes will catch them downstream while testing, so it wont ever miss
Rewieer
  • 890
  • 9
  • 7
  • 1
    here is a dedicated babel plugin already https://www.npmjs.com/package/babel-plugin-flow-react-proptypes – amankkg Jul 25 '18 at 09:46
16

Try declaring the type of props using only Flow. Specify an incorrect type, such as number instead of string. You'll see that this will be flagged in code that uses the component within your Flow-aware editor. However, this will not cause any tests to fail and your app will still work.

Now add use of React PropTypes with an incorrect type. This WILL cause tests to fail and be flagged in the browser console when the app is run.

Based on this, it seems that even if Flow is being used, PropTypes should also be specified.

Mark Volkmann
  • 746
  • 9
  • 13