Question

我正在学习React，我觉得我理解得很好。然而，有一件事情困扰我开发强大的React应用程序 - 开发人员使用什么工具进行静态类型检查？

我非常喜欢TypeScript。由于类型检查和其他简洁的功能，我认为它可以减少开发JavaScript应用程序的痛苦。 Visual Studio Code还提供了非常好的代码完成。我知道我可以使用typings + DenifitelyTyped将其与React配合使用。

问题是，关于使用React + TypeScript的教程并不多。似乎也没有很多关于使用这个组合进行开发的文章。另一方面，许多人似乎正在使用Flow，这是一个由Facebook支持的项目（我想他们也会使用它）。

我设法找到一个有关使用React + TypeScript / React + Flow方式的优缺点的discussion on Reddit。然而，对我来说，它似乎已经过时了，因为它现在已经有10个月了。我认为从那以后发生了很多变化。

我还发现了两篇关于使用React + Flow和React + TypeScript的文章。作者陈述了他在使用这两个选项时遇到的一些问题，并得出结论：TypeScript是“现在最好的选择”（2015年11月），特别是因为Flow项目有很多问题并且从Facebook获得的开发人员活动很少。他还提到它与巴贝尔不相称？

所以，我想问题是：使用React + TypeScript组合是否安全，还是会遇到一些困难？ Flow怎么样？我应该检查一些其他类似的工具吗？你会推荐哪种方法？

2017年9月更新：

拥有超过一年的日常使用TypeScript经验，并在一段时间内使用Flow，我得出以下结论：

今天使用TypeScript仍然很痛苦。问题是JavaScript世界的移动速度太快以至于TypeScript一直落后。考虑使用那个花哨的新ES7第3阶段功能？不，你不能。希望获得某些库的最新版本的类型提示？等一个月，或两个，或许更多......
Flow已经走过了漫长的道路，它已经得到了很大的改进，它可以捕获一些TS不能的东西。最重要的是，它最终适用于Windows。此外，还有很棒的VS Code插件（不知道为什么它只有3/5的评级）。它使用React Native 100％工作，TypeScript甚至不到50％。
大多数时候，你根本不需要类型。所有额外的打字很少值得。 JS是一种动态类型语言，克服它：）

TL; DR：如果您打算使用任何类型检查器，我建议使用Flow。

2019年2月更新：

我认为上述推荐已经过时且不再相关。原因有三：

React Hooks在这里。它们使代码的类型检查变得更加容易。 In most situations, no additional code is needed.
TypeScript的类型推断已得到改进。
TypeScript拥有比Flow更大的社区。甚至纱线，Facebook的包裹经理，is moving away from Flow, to TypeScript。

所以，我认为TypeScript比2019年的Flow更加务实。

至于是否值得使用任何类型的检查器，我会说这取决于项目的大小。小项目可能不需要它。

Answer 1

我将开始这个答案，说我从未使用Flow，所以我不能说太多。但是，我们正在使用React和TypeScript，它工作得很好。

我们拥有您已经知道的所有好处，例如重构，类型安全，自动完成等。

当然，对于我所看到的，Flow语法比TypeScript更清晰，但您可以使用TypeScript逐步添加类型。我想，这更多的是品味问题。有些人喜欢明确键入代码，有些人更喜欢键入较少的类型并具有更强的类型推断。

关于，我说TypeScript的技术是一个安全的选择，微软正在推动语言（there will be a version 2 soon），Angular也在使用它，并且有很多Angular开发人员。即使在这里，标签TypeScript也有超过4K的粉丝，而且很少有一个没有答案的问题。

TypeScript的一个大问题，至少对我们而言，我们不时会决定使用没有类型定义的组件或库，因此我们必须自己创建它们。但我想，这是回馈社区的一种方式。

Answer 2

我刚问自己同样的问题（虽然没有使用React），并发现以下文章对评估这两个问题很有用：

http://michalzalecki.com/typescript-vs-flow/（2016-07-15）
https://blog.wearewizards.io/flow-and-typescript-part-2-typescript（2015-11-20）
https://blog.wearewizards.io/flow-and-typescript-part-1-flow（2015-11-13）

流程设计人员采用的方法通过更好的类型推断和更好的空值方法感觉更具功能性。但是，TypeScript具有更好的社区支持，特别是在通过http://definitelytyped.org/为第三方库引入类型方面，这对于让类型流经所有代码以实现最大类型安全性非常重要。 TypeScript是由Microsoft创建的，它在编写编译器方面有着丰富的历史，并且在有利的方向上发展技术 - 这里值得注意的是C＃以及它们已经添加了非null类型的事实（2016-07-11）：https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

TypeScript似乎是今天更安全的赌注。

对于那些在现有代码库中尝试TypeScript的人，我发现我的tsconfig.json文件中的以下设置确实有助于TypeScript与JavaScript很好地共存（允许一次转换一个文件）：

{
    "compilerOptions": {
        "allowJs": true,
        "isolatedModules": true,
        ...
    }
}

Answer 3

在我的React开发中，我设置了一个非常复杂的Babel / Webpack / Flow / Mocha工具链，并且从未遇到任何Flow问题。需要付出一些努力来设置一切（Webpack最初可能令人生畏），但之后，它才有效。 Flow绝对是一种可行的方式，因为它是一种更窄，更集中的技术，因此更有可能与其他工具一起使用。相比之下，TypeScript尝试的不仅仅是类型推断/静态类型检查工具，因此它带来了额外的包袱和假设。因此，React是一个专门的工具，可以很好地完成一件事，而TypeScript实际上是一种基于JavaScript的语言。为了确保Microsoft驱动其主页，TypeScript文件通常也有不同的扩展名（.ts而不是.js），因为您现在使用的是另一种语言，得到它？

TypeScript使用代码生成来吐出JavaScript，而在Flow中，注释被简单地剥离，因此没有代码生成。过去，微软推广TypeScript的人习惯于声明代码生成是“文件本地的”（我不记得使用的确切术语）。这应该提供一个安慰的保证，TypeScript编译器没有做任何太神奇的事情。无论如何，我无法找到突出显示的声明。使用Flow，您不需要使用纯JavaScript（或者您为Babel配置的任何ECMA版本）编写这样的保证，并且注释就像我说的那样简单地剥离。

更不用说TypeScript来自一家专门从事不道德和有问题的技术实践的公司（我不排除TypeScript可能最终成为所有Embrace-Extend-Extinguish ploys的母亲）。让我们不要忘记，微软did everything in their power to cause Javascript to fail因为他们（正确的，如果姗姗来迟）预见到它所代表的威胁，并且仍然代表着他们糟糕的操作系统和臃肿的办公套件。

此外，Flow的类型系统在上次评估TypeScript（大约在2015年）时更加强大 更强大，并且更容易在源中逐步或甚至零星地应用它。为了集成第三方库，我正在使用flowtyped，我很少需要用我自己的定义来补充那里发现的那些。

最后，Angular使用TypeScript这一事实绝对没有意义，因为Angular与新项目并不真正相关。 React已经取得了成功，有时间继续前进。

Answer 4

如果您想要类型检查但更愿意保留普通的旧 javascript（以避免编译，或为了可移植性等），这是两者之间的一个重要区别（对于 React 或一般而言）：

借助 Flow，initial setup 可以在普通 js 上运行静态分析（它推断多种类型）：
```
function square(n) {
  return n * n; // Error!
}

square("2");
```
TypeScript 有一个 migration effort，只有 some vanilla js static analysis 没有它：
- noImplicitReturns 防止您忘记在函数结束时返回。
- noFallthroughCasesInSwitch 如果您永远不想忘记 switch 块中 case 之间的 break 语句，这会很有帮助。
- TypeScript 还会警告无法访问的代码和标签，您可以分别使用 allowUnreachableCode 和 allowUnusedLabels 禁用它们。

流动带来的更多好处

Flow 的 Comment Types 和 Error Suppression 进一步支持 vanilla js，允许您通过合法的 js 注释逐步合并类型检查，这些注释对类型进行注释或禁止您可能还没有准备好的特定检查然而。评论类型在 TypeScript 中一直是 feature request 已经有一段时间了，直到最近才有了它的 PR（请参阅上一个链接）。

流动的缺点

也就是说，Flow 的所有简单性都以一些漂亮的 complex configuration 为代价，并带有一些烦人的警告，例如它如何 type checks 3rd party libraries 等。有人可以提供关于 Flow 的最佳建议：尝试交叉引用您在他们的文档中阅读的任何内容，因为它已经过时并且在某些情况下可能会引起一些误导。

React - 使用TypeScript vs Flow vs？

4 个答案: