React - 使用 TypeScript vs Flow vs?

React - using TypeScript vs Flow vs?

提问by Honza Kalfus

I'm currently learning React and I think I understand it pretty well. However, there's one thing that's been bothering me regarding development of robust React applications - what tools do developers use for static type checking?

我目前正在学习 React，我认为我对它非常了解。然而，关于开发健壮的 React 应用程序，有一件事情一直困扰着我——开发人员使用哪些工具进行静态类型检查？

I really like TypeScript. I think it reduces the pain of developing JavaScript applications quite a lot, thanks to type checking and other neat features. Visual Studio Code also offers a really nice code completion. And I know that I can make it work with React by using typings+ DenifitelyTyped.

我真的很喜欢 TypeScript。我认为由于类型检查和其他简洁的功能，它大大减少了开发 JavaScript 应用程序的痛苦。Visual Studio Code 还提供了非常好的代码完成功能。我知道，我可以把它与利用工作做出反应分型+ DenifitelyTyped。

The thing is, there aren't many tutorials about using React + TypeScript. There also doesn't seem to be many articles about developing using this combo. On the other hand, many people seem to be using Flow, which is a project backed by Facebook (and I guess they also use it).

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

I've managed to find a discussion on Redditwith pros and cons about going the React + TypeScript / React + Flow way. However, to me, it appears to be quite outdated as it is about 10 months old now. I think a lot has changed since then.

我设法在 Reddit上找到了关于采用 React + TypeScript / React + Flow 方式的利弊的讨论。然而，对我来说，它似乎已经过时了，因为它现在大约有 10 个月大了。我认为从那以后发生了很多变化。

I've also found two articles about using React + Flowand React + TypeScript. The author states some issues he's run into when using both of the options and concludes that TypeScript is "the best bet right now" (November 2015), especially because the Flow project has many issues and receives low developer activity from Facebook. He also mentions it doesn't play well with Babel?

我还发现了两篇关于使用React + Flow和React + TypeScript 的文章。作者陈述了他在使用这两个选项时遇到的一些问题，并得出结论认为 TypeScript 是“目前最好的选择”（2015 年 11 月），尤其是因为 Flow 项目有很多问题，而且 Facebook 的开发人员活动很少。他还提到它不适合与 Babel 配合使用？

So, I guess the question would be: Is it safe to use the React + TypeScript combo, or will I run into some difficulties? What about Flow? Are there some other similar tools I should check out? Which approach would you recommend?

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

Update September 2017:

2017 年 9 月更新：

Having more than a year of experience with daily use of TypeScript, and playing with Flow for a while, I've came to the following conclusions:

有一年多的 TypeScript 日常使用经验，玩了一段时间 Flow，得出以下结论：

• TypeScript is still painful to use to this very day. The problem is that the JavaScript world just moves so fast that TypeScript keeps lagging behind. Thinking about using that fancy new ES7 stage 3 feature? Nope, you can't. Wishing to get type hints for the latest version of some library? Wait a month, or two, maybe more...
• Flow has come a long way, it has been improved a lot, it can catch some things that TS can't. Best of all, it finally works on Windows. Also, there's great plugin for VS Code (no idea why it has only 3/5 rating). And it works 100 % with React Native, TypeScript is not even 50 % there yet.
• Most of the time, you don't need types at all. All the additional typing is rarely worth it. JS is a dynamically typed language, get over it :)

• 直到今天，TypeScript 使用起来仍然很痛苦。问题是 JavaScript 世界发展得太快，以至于 TypeScript 一直落后。考虑使用新的 ES7 第 3 阶段功能吗？不，你不能。希望获得某些库的最新版本的类型提示？等一两个月，也许更久……
• Flow走了很长一段路，进步了很多，它可以捕捉到一些TS无法做到的东西。最重要的是，它终于可以在 Windows 上运行了。此外，VS Code 有很棒的插件（不知道为什么它的评分只有 3/5）。它可以 100% 使用 React Native，而 TypeScript 甚至还不到 50%。
• 大多数时候，您根本不需要类型。所有额外的打字很少值得。JS 是一种动态类型语言，克服它:)

TL;DR: If you plan to use any type checker, I recommend using Flow.

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

Update February 2019:

2019 年 2 月更新：

I believe the recommendation above got out of date and is no longer relevant. Three reasons:

我相信上面的建议已经过时，不再相关。三个原因：

• React Hooksare here. They make type-checking your code much easier. In most situations, no additional code is needed.
• TypeScript's type inference has improved.
• TypeScript has much bigger community than Flow. Even yarn, Facebook's package manager, is moving away from Flow, to TypeScript.

• React Hooks在这里。它们使对您的代码进行类型检查变得更加容易。在大多数情况下，不需要额外的代码。
• TypeScript 的类型推断得到了改进。
• TypeScript 的社区比 Flow 大得多。甚至 Facebook 的包管理器 yarn也正在从 Flow 转向 TypeScript。

So, I think TypeScript is a much more pragmatic choice than Flow in 2019.

所以，我认为 TypeScript 在 2019 年是一个比 Flow 更务实的选择。

As to whether it's even worth using any type checker at all, I'd say it depends on the project size. Small projects probably don't need it.

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

采纳答案by thitemple

I'm going to start this answer saying that I have never used Flow, so I can't say much about it. But, we are using React and TypeScript at work and it works great.

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

We have all the benefits I imagine you already know about, like refactoring, type safety, autocompletion, etc.

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

Sure, for what I have seen, the Flow syntax is cleaner than TypeScript, but you can add your types using TypeScript incrementally. I think, this is more a matter of taste. Some people prefer to have the code explicitly typed, others prefer to type less and have a stronger type inference.

当然，就我所见，Flow 语法比 TypeScript 更简洁，但您可以使用 TypeScript 逐步添加类型。我认为，这更像是一个品味问题。有些人喜欢显式键入代码，而另一些人则喜欢少键入并具有更强的类型推断。

About, the technologies I'd say TypeScript is a safe bet, Microsoft is pushing the language (there will be a version 2 soon), Angular is using it as well and there are a lot of Angular developers. Even here on SO, the tag TypeScript has more than 4K followers and it's rare to have an unanswered question.

关于技术，我认为 TypeScript 是一个安全的赌注，微软正在推动该语言（即将推出第 2 版），Angular 也在使用它，并且有很多 Angular 开发人员。即使在 SO 上，标签 TypeScript 也有超过 4K 的关注者，而且很少有人提出未回答的问题。

The big issue with TypeScript, at least for us is that from time to time, we decide to use a component or a library that does not have the type definitions, so we have to create them ourselves. But I guess, that's a way to contribute back to the community.

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

回答by Spritely

I just asked myself the same question (though not with React) and found the following articles useful in evaluating the two:

我只是问自己同样的问题（虽然不是用 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)

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

The approach taken by the flow designers feels more functional with better type inference and a better approach for nulls. However, TypeScript has better community support especially with respect to pulling in types for third party libraries via http://definitelytyped.org/which is important for having types flow through all your code for maximum type safety. TypeScript is created by Microsoft which has a rich history in writing compilers and evolving the technology in favorable directions - notable here is C# and the fact that they are already adding non-null types (2016-07-11): https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

流程设计者采用的方法通过更好的类型推断和更好的空值方法感觉更实用。然而，TypeScript 有更好的社区支持，尤其是在通过http://definelytyped.org/为第三方库引入类型方面，这对于让类型在所有代码中流动以实现最大类型安全非常重要。TypeScript 由 Microsoft 创建，该公司在编写编译器和向有利方向发展技术方面拥有丰富的历史 - 这里值得注意的是 C# 以及他们已经添加非空类型的事实（2016-07-11）：https://blogs .msdn.microsoft.com/typescript/2016/07/11/annoucing-typescript-2-0-beta/

TypeScript seems like the safer bet today.

今天，TypeScript 似乎是更安全的选择。

And for those trying TypeScript out in an existing codebase I found the following settings in my tsconfig.json file really helpful in allowing TypeScript to co-exist nicely with JavaScript (allowing transition one file at a time):

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

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

回答by Marcus Junius Brutus

In my React development, I have quite a complex Babel/ Webpack/ Flow/ Mochatoolchain set up and never had any issues with Flow. Takes some effort to set everything up (Webpack can be daunting at first), but afterwards, it just works. Flow is definitely the way to go as it is a narrower and more focused technology and as such more likely to play well with other tools. In contrast, TypeScript tries to be a lot more than just a type inference / static type checker tool and so it brings additional baggage and assumptions. So React is a specialized tool that does one thing well while TypeScript is effectively a language layered on top of JavaScript. To make sure Microsoft drives its point home, TypeScript files customarily have a different extension as well (.tsinstead of .js) because you are now using a different language, got it?

在我的 React 开发中，我有一个相当复杂的Babel/ Webpack/ Flow/ Mocha工具链设置并且从未遇到过任何 Flow 问题。设置一切需要一些努力（Webpack 一开始可能令人生畏），但之后，它就可以工作了。Flow 绝对是要走的路，因为它是一种更窄、更专注的技术，因此更有可能与其他工具配合得很好。相比之下，TypeScript 试图不仅仅是一个类型推断/静态类型检查器工具，因此它带来了额外的负担和假设。所以 React 是一种专门的工具，可以很好地做一件事，而 TypeScript 是一种有效的基于 JavaScript 的语言。为确保 Microsoft 深入了解，TypeScript 文件通常也具有不同的扩展名（.ts而不是.js），因为您现在使用的是不同的语言，明白了吗？

TypeScript uses code generation to spit out JavaScript whereas in Flow the annotations are simply stripped off, there's no code generation as such. In the past, the Microsoft people promoting TypeScript used to make a statement to the effect that code generation is "file-local" (I don't remember the exact terminology used). This was supposed to provide a soothing reassurance that the TypeScript compiler isn't doing anything too magical. At any rate I can't find that statement prominently displayed any more. With Flow you don't need such assurances as you write in plain JavaScript (or whatever ECMA version you've configured Babel for) and the annotations are, like I said, simply stripped.

TypeScript 使用代码生成来生成 JavaScript，而在 Flow 中，注释被简单地剥离，没有代码生成。过去，微软宣传 TypeScript 的人常常声明代码生成是“本地文件”（我不记得使用的确切术语）。这应该提供一种安慰性的保证，即 TypeScript 编译器不会做任何太神奇的事情。无论如何，我再也找不到那个显眼的声明了。使用 Flow，您不需要像使用纯 JavaScript（或您为 Babel 配置的任何 ECMA 版本）编写时那样的保证，并且注释就像我说的那样，只是被剥离了。

Not to mention that TypeScript is coming from a company that specializes in unethical and questionable technical practices (I don't rule out that TypeScript may eventually turn out to be the Mother of all Embrace-Extend-Extinguish ploys). Let's not forget that Microsoft did everything in their power to cause Javascript to failas they (rightly, if belatedly) foresaw what a threat it represented, and still represents, to their crappy operating system and their bloated office suite.

更不用说 TypeScript 来自一家专门从事不道德和有问题的技术实践的公司（我不排除 TypeScript 最终可能成为所有 Embrace-Extend-Extinguish 策略之母）。让我们不要忘记，微软尽其所能导致 Javascript 失败，因为他们（正确地，如果为时已晚）预见了它对他们蹩脚的操作系统和臃肿的办公套件所代表的威胁，并且仍然代表着。

Additionally, Flow's type system was muchmore powerful last time I bothered to evaluate TypeScript (circa 2015) and it was much easier to apply it incrementally or even sporadically in the sources. For integrating third party libraries I am using flowtypedand it is very rare that I need to complement those found there with my own definitions.

此外，流量的类型系统是很多更强大我不屑于评价打字稿（大约2015年）最后一次，并在源增量，甚至偶尔运用它容易得多。集成第三方库我使用flowtyped，这是非常罕见的，我需要补充那些用我自己的定义在那里发现。

Finally, the fact that Angular uses TypeScript means absolutely nothing as Angular is not really relevant for new projects. React has won hands down, time to move on.

最后，Angular 使用 TypeScript 的事实绝对没有任何意义，因为 Angular 与新项目并不真正相关。React 已经赢了，是时候继续前进了。