我正在使用带有Flow的React。如果我在渲染时忘记设置一些需要的道具，则Flow会给我错误，以便我防止出现该问题。
但是Flow实际上在运行时上不起作用。因此，如果我使用的值被视为数字而不是数字，则Flow不能捕获此值。例如，如果该值来自服务器端等其他地方，并且它是字符串，但是Flow只是将其视为数字，那么最终我将在运行时遇到一些错误。
但是PropTypes在运行时有效，因此在相同情况下，我会收到错误消息，即PropType期望的数字，但实际上是字符串。
当API更改且返回数据不同时，也可能发生这种情况。它可以是未定义的或任何其他内容，可能不是我期望的实际值。
所以我实际上同时使用了Flow和PropTypes，但是我搜索了两者的结合使用，但是找不到任何相关信息。
相反，我发现的只是将“ Flow”替换为“ PropTypes”。我不这么认为，我已经提到了两者之间的区别。我认为，这两种作品完全不同，并且每一种都有很多好处，因此将它们结合起来将产生很好的协同作用。
但是现在我同时使用这两种方法，我必须为props定义类型，还必须始终定义propTypes和defaultProps，这实际上使我的代码很长，并且仅花费一个组件就花费很多时间。
我应该停止同时使用Flow和PropTypes吗？我认为Flow比PropTypes好，使用静态类型检查器有很多好处，所以我想继续使用它。此外，Flow还提供了很好的VSCode支持，但原型没有。
如果我使用Flow，是否不需要PropTypes？任何建议将不胜感激。
答案 0 :(得分：1)
Flow允许您提供任何内容的类型。
PropTypes仅用于组件的props，因此无法帮助键入变量或方法。它甚至没有简单的方法来键入回调道具。您将需要描述custom validator。
PropTypes也基于每个属性工作。您无法描述道具的独立子集。例如。 “仅在昵称为空时才需要字段名称”。我同意这听起来对本示例没有太大帮助。但这仍然意味着流程更加灵活。
反正在生产中进行类型检查是个坏主意-这会导致性能下降。同时，大多数类型问题也已被发现。尽管它仍然不能使您摆脱逻辑问题的困扰，所以您将需要使用手动/验收/集成测试进行测试。