前端深爱的 TypeScript,是库开发者的“噩梦”

e9987beca723b532eaad5d6958eefa48.gif

摘要:使用过 TypeScript 的前端开发者们,大多对 TypeScript 抱有好感,TypeScript 如今在前端领域也占据核心一隅。然而,在库开发者的眼里,TypeScript 似乎就很不“友好”了,本文作者亦是如此认为的。你在使用 TypeScript 时,是否遇到过这些问题呢?

原文链接:https://erock.prose.sh/typescript-terrible-for-library-developers

声明:本文为 CSDN 翻译,未经授权禁止转载。

作者 | Eric Bower

译者 | 弯月

出品 | CSDN(ID:CSDNnews)

以下为译文:

作为一名前端开发人员,我非常喜欢TypeScript。我感觉TypeScript大幅削减了手动编写自动化测试的需求,减轻了编写和维护自动化测试的负担,推动了开发人员生产力的提升。

但是,作为库开发人员,我非常讨厌TypeScript。我认为TypeScript不适合库开发,其中的原因有很多,但归根结底还是因为Typescript降低了开发人员的工作效率。实际上,我认为TypeScript将软件开发的复杂性从前端开发人员转嫁到了库开发人员,给每个希望成为TypeScript专家的人带来了巨大负担。

前端深爱的 TypeScript,是库开发者的“噩梦”_第1张图片

文档

TypeScript面向前端开发人员的文档和博客文章很丰富,但面向库开发人员的资源却很少。我所能找到的面向库开发人员的只有这一段有关类型操作的介绍(https://www.typescriptlang.org/docs/handbook/2/types-from-types.html)。

可能是因为他们认为库开发人员和前端开发人员并没有什么区别,恕我不能赞同。

为什么TypeScript官网没有提供任何有关库开发的指南?也没有任何推荐给库开发人员的工具指南?

事实上,TypeScript的应用开发与库开发之间存在一个巨大的鸿沟。Web应用很少需要条件类型、类型运算符和重载等结构。但库开发人员需要大量使用这些结构。这些构造是高度动态的,而且会在类型中加入逻辑。这导致我对TypeScript的调试大失所望。

调试

库开发人员如何调试高度动态且大量使用的条件类型以及负载?调试唯一可用的工具只有TypeScript的编译器和专业知识。你可以修改代码,然后看看类型最终的结果。在我看来,库开发人员只能凭直觉,除此之外没有任何更好的解决方案。

据我所知,库开发人员大量使用的唯一工具就是TypeScript演练场,他们可以在这个环境中将类型的逻辑分离出来,研究TypeScript将类型解析为另一种类型的原因。此外,你还可以在这个环境中轻松地修改TypeScript的版本和配置。

如果你知道任何TypeScript的调试工具,请不吝指教,因为我写这篇文章,不仅仅是为了发牢骚,更希望高人指点迷津。

复杂性

我使用了很长时间的redux,在我看来redux-toolkit是一个很了不起的库,你可以借助这个库查看真实的代码库是如何使用类型的。我必须说明,它们在类型方面的表现非常出色,但复杂度非常惊人。

下面是两个例子:

  • createAction #1:https://github.com/reduxjs/redux-toolkit/blob/4ab8c42cb20ae1e6f7b84a8ac0070eee54775b79/packages/toolkit/src/createAction.ts#L58

  • createAction #2:https://github.com/reduxjs/redux-toolkit/blob/4ab8c42cb20ae1e6f7b84a8ac0070eee54775b79/packages/toolkit/src/createAction.ts#L193

这个代码库中充斥着各种复杂类型。请注意类型的数量与实际的代码量。我大致统计了一下(忽略导入的代码),该文件中只有约10%的代码转译成了js代码(js代码:35行,代码总数:330行)。

风格指南中总是强调,不要使用嵌套的三元运算符。然而,在TypeScript中,你只能通过这种方式根据其他类型来缩小类型的范围。

测试

由于类型可以根据其他类型生成,而且这些类型高度动态,所以任何严肃的TypeScript项目都需要一类新型的测试:测试类型。在最新版本的TypeScript编译器上测试类型远远不够,你还需要针对以前的版本进行测试。

这类新型的测试还处于起步阶段,相关的工具有些已被弃用,而有些处于半维护状态。我曾使用过的库如下:

  • DefinitelyTyped-tools:https://github.com/microsoft/DefinitelyTyped-tools

  • tsd:https://github.com/SamVerschueren/tsd

  • dtslint:https://github.com/microsoft/dtslint

  • typings-checker(已被弃用):https://github.com/danvk/typings-checker

该领域的人才大量流失,我的一些项目至今仍在使用已弃用的库,因为迁移代码会非常痛苦。

值得推荐的工具似乎只有两个:dtslint 和 tsd。为什么我们需要两个工具来完成大致相同的工作?这一点很令人迷惑。

维护

类型导致代码量急剧增加。当第一次尝试为项目贡献代码时,你必须了解应用程序的逻辑以及类型的逻辑。这会导致我们的心理压力增加,同时还会导致代码量急剧增加。举个例子,我在帮忙维护redux-saga,最近大多数的拉取请求和议题都是与类型相关的。

我花费在调整类型上的时间远远超过了编写库的代码。

虽然我很熟悉TypeScript,但我并不是专家。虽然我花费了数年时间编写TypeScript代码,但作为库开发人员,我仍然没有足够的知识来使用TypeScript,这让我倍感沮丧。精通语言似乎是一个先决条件。类型使得维护js库的难度加剧,为这些库贡献代码更是难上加难。

总结

我很喜欢TypeScript,而且我也同意TypeScript对前端开发有很大的帮助。TypeScript彻底改变了前端开发的格局,我们无法忽视它带来的巨大影响。

但作为库开发人员,我们需要:

  • 更好的文档;

  • 更好的工具;

  • 减少花在讨tsc欢心的时间。

我只不过是为了弄清楚为什么TypeScript将一段代码解析为特定类型,也不至于要求我阅读TypeScript编译器的源代码吧?

— 推荐阅读 —

前端深爱的 TypeScript,是库开发者的“噩梦”_第2张图片

你可能感兴趣的:(资讯,java,python,编程语言,人工智能,c++)