首先是免责声明：TypedJavaScript很棒。我用过Flow，现在和将来都会继续使用TypeScript。不可否认，它是快速开发的强大工具。然而，它是万能的吗？显然不是，这股强大力量背后的代价是什么，值得思考，我们需要正视它的利弊。让子弹飞一会儿，看看打字的JavaScript的陷阱~代码很容易变得冗长其实在TypeScript和Flow中手动打字并不是什么好事！它使代码更冗长、更容易出错并且更难管理。理想情况下，TypeScript从数据库和定义的语言中推断类型。这样，我们可以从类型安全中获益，只需要管理自定义对象类型。但冗余确实很难避免。看一下用TypeScript编写的基于类的简单React组件：={name:'Piotr'};render(){returnthis.props.children(this.state);}}这是一个简单的基于类的React组件：exportclassNameProviderextendsReact.Component{state={name:'Piotr'};render(){返回this.props.children(this.state);}}查看rawplainComponent.js|GitHubTypeScript版本的代码增加了248%。工装和运行状态确实好多了，但是可读性呢？看看处理Redux操作的类型例子，很熟练很实用，再也不用担心类型转换出问题了...typeInferValueTypes=Textends{[key:string]:inferU}?U:never;typeActions=ReturnType>手工写的类型容易出错假设一个大团队正在做一个项目，John写了下面的类型定义：typePropsA={name:string,date:Date,url:string}Pablo在写的时候并没有意识到类型已经存在，所以他创建了一个类似的类型：typePropsB={name:string,date:string,url:string}现在有多余的类型，更糟糕的是，因为定义PropsB的略有不同，很难做出明确的类型定义。这种情况经常发生，即使是在价值数百万美元的大型项目中也是如此。来源：unsplash许多数据库缺乏类型尽管类型化生态系统正在快速发展，但它远未达到100%的应用。这意味着在许多情况下，您必须自己做。然而，每个大型项目最终都会推出一些非标准的自定义类型（或从GitHub问题中复制它们）以应用于某些库或用例。即使是最流行的库，如Redux，在没有规范类型的情况下也难以管理应用程序状态、表单转换等。给人一种错误的安全感虽然这可能不是最好的方法，但假设你定义了一个像这样的redux动作：使用旧动作作为模板复制新动作时，很容易发生以下情况：exportconstMY_NEW_ACTION:'MY_BASIC_ACTION'='MY_BASIC_ACTION'看到问题了吗？我们刚刚用第一个动作的类型定义了一个新动作。这很难检查，因为您应该发送MY_NEW_ACTION，但您发送的是MY_BASIC_ACTION。使用Flow/TypeScript时，你会感到非常安全和毫无防备。当您意识到问题变得如此棘手时，您可能想用头撞墙几个小时！来源：unsplash类型管理本身就是一项技能JavaScript已经很容易理解，但是正确有效地向此写入类型添加类型需要动态、无害语言的高超技能。避免使用类型化的JS并不是避免困难的借口，但对于期限紧迫的现实世界项目或对于大多数初级开发人员来说，这可能是必要的。在大多数情况下，你可能只需要对一个组件的属性、状态等进行分类。但是这个问题，总有一天你不得不面对它。一个强大的IDE可能就是你所需要的全部VSCode中的IntelliSense结合整理工具，开发人员可以从TypeScript和Flow中获得更多便利。IDE支持将使您非常富有。我敢打赌，您会惊讶于TypeScript被忽视的程度如此之少。没有类型安全的编码可以提供JavaScript的全部功能——毕竟，它是设计来的松散类型编码——并且让您格外小心。管理更多配置构建类型化操作系统并非易事，需要使用构建工具、管理配置文件、创建更多依赖项等。您需要在曾经易于集成的库中找到一个单独的部分，以便与TypeScript一起使用。而最痛苦的是，你可能会花很多时间在GitHub上搜索解决方案，让LibraryZ与Flow或TypeScript一起工作。真正的成就是一个没有类型但仍然可以浏览和自我记录的项目。也许你认为我讨厌TypeScript，但恰恰相反，我真的很喜欢TypeScript，并且深深地理解它的好处。但是，工欲善其事必先利其器，还要理性地发掘它的缺陷，不是吗？
