先别用 TypeScript了!

552 篇文章 2 订阅

全文共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<NameProviderProps, NameProviderState> {
                                   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> = T extends { [key: string]: infer U } ? U : never;

type Actions = ReturnType<InferValueTypes<typeof actions>>

 

 

手动写入的类型很容易出错

 

假设一个大团队正在从事一个项目,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的疏忽之处如此之少。

 

图源:creative-tim

 

没有类型安全的编码提供了JavaScript的全部功能——毕竟,它是基于设计的松散类型化编码——并使你对此格外小心。

 

 

更多要管理的配置

 

建立类型化的操作系统并不简单,需要使用构建工具,管理配置文件,并创建更多依赖项等。你需要在曾经易于集成的库中寻找一个单独的部分,用以与TypeScript搭配使用。

 

而最痛苦的是,你可能会花费大量时间在GitHub中搜索解决方案,以使LibraryZ与Flow或TypeScript一起使用。

 

 

图源:unsplash

 

真正的成就是,没有类型但仍然可以浏览和自记录的项目。或许你会觉得我讨厌TypeScript,但恰恰相反,我非常喜欢TypeScript,我对它的好处深有体会。

 

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

 

留言 点赞 关注

我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

(添加小编微信:dxsxbb,加入读者圈,一起讨论最新鲜的人工智能科技哦~)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值