先别用TypeScript了！

首先必须要声明：类型化JavaScript非常棒。

我使用过Flow，现在和将来也都将继续使用TypeScript。不可否认，这是一个快速发展的强大工具。

然而，它是无所不能的吗?显然不是，这种强大力量背后的代价是什么，值得我们思考，我们需要正视其利弊之处。

让子弹先飞一会儿，来看看类型化JavaScript的缺陷吧~

代码很容易变得冗长

事实上，TypeScript和Flow的手动类型化并不是一件好事!它使代码更冗长，容易出错并且更难管理。

理想情况下，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);
  
  
  
                                   }
  
  
  
                                 }
 
 
 

这是一个简单的基于类的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，一旦缺乏规范的类型，也很难管理好应用状态、形式转换程序等。

给予错误的安全感

虽然这可能不是最好的方法，但是假设你定义了一个redux操作，如下所示：

 
 
 

  
  
  
exportconst MY_BASIC_ACTION: ‘MY_BASIC_ACTION’ = ‘MY_BASIC_ACTION’
 
 
 

其中一些操作很简单，但是当你面临30种操作类型，在以旧操作作为模板复制新操作时，很容易发生以下情况：

 
 
 

  
  
  
exportconst MY_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，我对它的好处深有体会。

但是，工欲善其事必先利其器，理性探讨它的缺陷也是必要的，不是吗?

网站标题：先别用TypeScript了！
网站地址：http://www.shufengxianlan.com/qtweb/news18/411668.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联