『TypeScript』先别用 TypeScript了！ |JavaScript|GitHub|FLOW|

全文共1740字，预计学习时长8分钟

本文插图
图源：clearboxseo
首先必须要声明：类型化JavaScript非常棒。
我使用过Flow ，现在和将来也都将继续使用TypeScript 。不可否认，这是一个快速发展的强大工具。
然而，它是无所不能的吗？显然不是，这种强大力量背后的代价是什么，值得我们思考，我们需要正视其利弊之处。
让子弹先飞一会儿，来看看类型化JavaScript的缺陷吧~

本文插图
代码很容易变得冗长
事实上， TypeScript和Flow的手动类型化并不是一件好事！它使代码更冗长，容易出错并且更难管理。

本文插图
图源：unsplash
理想情况下， TypeScript会从数据库以及已定义的语言中推断类型。这样，我们就可以从类型安全中受益，只需管理自定义对象类型。
但冗余真的很难避免。来看看用TypeScript编写的基于类的简单React组件：
interface NameProviderProps {children: (state: NameProviderState) =>React.ReactNode;}interfaceNameProviderState {readonly name: string;}exportclassNameProviderextendsReact.Component {readonly state: NameProviderState= { name: 'Piotr' };render() {return this.props.children(this.state);}} view rawtypescriptComponent.js | GitHub
这是一个简单的基于类的React组件：
exportclassNameProviderextendsReact.Component {state= { name: 'Piotr' };render() {return this.props.children(this.state);}} view rawplainComponent.js | GitHub
TypeScript版本的代码增加了248％。工具和运行状态的确好了很多，但可读性呢？
只需看一下处理Redux操作的类型示例，非常熟练且实用，你不必再担心陷入类型转换带来的麻烦……
typeInferValueTypes = T extends { [key: string]: infer U } ? U : never;type Actions = ReturnType>

本文插图
手动写入的类型很容易出错
假设一个大团队正在从事一个项目， John编写了以下类型定义：
typePropsA = { name: string, date: Date, url: string}
编写之时， Pablo并未意识到类型已经存在，因此他创建了一个类似的类型：
typePropsB = { name: string, date: string, url: string}
现在便有了冗余类型，更糟糕的是，因PropsB的定义稍有不同，便很难再进行明确的类型定义。
这样的事情不在少数，投入数百万美元的大型项目中也时有发生。

本文插图
图源：unsplash

本文插图
许多数据库缺乏类型
尽管类型化生态系统发展迅速，但它还远没有达到100％应用。这意味着在许多情况下，你得自己上手。
但是，每个大型项目最终都会推出一些不规范的自定义类型（或从GitHub问题中复制它们）来应用于一些库或用例。
即使是最流行的库，例如Redux ，一旦缺乏规范的类型，也很难管理好应用状态、形式转换程序等。