反应原型与流程

PropType 和 Flow 涵盖了类似的内容,但使用了不同的方法。PropType 可以在运行时提供警告,这有助于快速查找来自服务器的异常响应,等等。然而,Flow 似乎是未来的趋势,并且使用泛型等概念是一种非常灵活的解决方案。此外,自动完成提供的核素是一个很大的优势流。

我现在的问题是,当开始一个新项目时,哪种方式是最好的。或者同时使用 Flow 和 PropType 会是一个好的解决方案吗?同时使用这两种方法的问题在于要编写大量重复的代码。这是我写的一个音乐播放器应用程序的例子:

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


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

两个定义基本上包含相同的信息,当数据类型发生更改时,需要更新两个定义。

我发现这个 Babel 插件可以将类型声明转换为 PropType,这可能是一个解决方案。

24429 次浏览

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.

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).

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.

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