PropTypes reaction against flow

Question

PropTypes and Flow cover similar things, but use different approaches. PropTypes can give you warnings at runtime, which can be useful for quickly finding incorrect answers coming from the server, etc. However, Flow seems to be the future, and with concepts like generics, it is a very flexible solution. Also, autocomplete offered by Nuclide is a big plus for the flow.

Now my question is the best way to start 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 music player application that 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 changes, both definitions need to be updated.

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

Answer 1

A year after I asked this question, I wanted to give updated information on how my experience with this problem.

Since the thread involved a lot, I started to enter my code base with it and did not add any new PropType definitions. Until now, I think this is a good way to go, because, as mentioned above, it allows you to not only type in details, but also other parts of your code. This is very convenient, for example, when you have a copy of your details in a state that can be changed by the user. In addition, auto-completion in the IDE is an amazing enhancement.

Automatic converters in one direction or another were not removed. Therefore, for new projects, I would really recommend using a stream over PropTypes (in case you do not want to print twice).

Answer 2

Besides the fact that both belong to a very wide field of type checking, there is not much similarity between them.

A stream is a static analysis tool that uses a superset of the language, allowing you to add type annotations to your entire code and catch the entire class of errors at compile time.

PropTypes is a basic type of validation that has been fixed on React. It cannot check anything but the types of props passed to this component.

If you need a more flexible type checking method for the whole project, then Flow / TypeScript are the right options. As long as you only pass annotated types to components, you won't need PropTypes.

If you just want to check the types of support, do not unnecessarily complicate the rest of your code base and use a simpler option.

Answer 3

Try declaring the type of props using only Flow. Specify the wrong type, for example, a number instead of a string. You will see that this will be tagged in the code that uses the component in your stream editor. However, this will not lead to test failures, and your application will still work.

Now add using React PropTypes with the wrong type. This will cause the tests to fail and will be flagged in the browser console when the application starts.

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

Answer 4

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

• Flow can catch errors upstream during coding: theoretically, it can skip some errors that you don’t know about (if you haven’t implemented the stream enough in your project, for example, or in the case of a deep nested object)
• PropTypes will catch them during testing, so it will never miss