TypeScript值得吗?

2020年12月30日11:16:22 发表评论 44 次浏览

本文概述

在开始之前, 我希望陪审团知道我在很大程度上是TypeScript爱好者。对于前端React项目和我所做的任何后端Node工作, 这是我的主要编程语言。我正在上任, 但我确实有一些疑惑, 我想在这篇文章中进行讨论。我现在至少用TypeScript编写了三年以上的众多合同, 所以TypeScriptis做正确的事情或满足需要。

TypeScript克服了一些无法克服的困难, 成为前端编程领域的主流。 TypeScript排在第七这个帖子列出了最受欢迎的编程语言。

无论是否使用TypeScript, 任何规模的软件团队都应遵循以下惯例:

  • 编写良好的单元测试应涵盖合理范围内的尽可能多的生产代码
  • 结对编程–额外的视线可以捕捉到的错误远远超过语法错误
  • 良好的同行评审过程-正确的同行评审会捕获机器无法解决的许多错误
  • 棉绒的使用, 例如埃斯林特

TypeScript可以在这些之上增加额外的安全性, 但是我认为在需求编程语言列表中, 它仅次于国家/地区。

TypeScript不是声音类型系统

我认为这可能是当前TypeScript化身的主要问题, 但首先让我定义一下声音和不健全类型系统。

健全性

一种声音类型系统是一种确保程序不会进入无效状态的系统。例如, 如果表达式的静态类型为String, 在运行时, 你只能保证获得一个String当你评估它时。

在声音类型系统中, 永远不要在编译时就位或运行时表达式与预期类型不匹配的地方。

当然, 健全性健全性易于解释。 TypeScript具有一定的声音, 并会捕获以下类型错误:

// Type 'string' is not assignable to type 'number'
const increment = (i: number): number => { return i + "1"; }

// Argument of type '"98765432"' is not assignable to parameter of type 'number'.
const countdown: number = increment("98765432");

不健全

Typescript完全是关于以下事实的:100%的稳固性不是目标, 也是目标的非目标3。TypeScript的非目标明确指出:

应用健全或"正确无误"的类型系统。相反, 要在正确性和生产率之间取得平衡。

这意味着不能保证变量在运行时具有定义的类型。我可以用下面一些人为的例子来说明这一点:

我们为制作了一个自定义演示.
不完全是。点击这里查看.

TypeScript值得吗?1
interface A {
    x: number;
}

let a: A = {x: 3}
let b: {x: number | string} = a; 
b.x = "unsound";
let x: number = a.x; // unsound

a.x.toFixed(0); // WTF is it?

上面的代码是不健全因为斧头从中得知是一个数字一种接口。不幸的是, 经过一些重新分配后, 它最终以字符串形式出现, 并且以下代码在运行时编译但出错。

不幸的是, 这里显示的表达式可以正确编译:

a.x.toFixed(0);

我认为这可能是TypeScript的最大问题, 因为健全性不是目标。我仍然遇到许多运行时错误, 这些错误并未被tsc如果TypeScript具有声音系统, 则为编译器。通过这种方法, TypeScript在声音和声音不熟悉的阵营中都只有一只脚。这种半途而废的做法是通过任何类型, 我将在稍后提及。

我仍然必须编写尽可能多的测试, 这让我感到沮丧。当我第一次开始使用TypeScript时, 我错误地得出结论, 我可以停止编写这么多单元测试的工作。

TypeScript挑战了现状, 声称降低使用类型的认知开销比类型健全更重要。

我理解为什么TypesScript会走这条路, 并且有一个论点指出, 如果声音类型系统得到100%保证, 那么对TypeScript的采用不会那么高。这被反驳为飞镖语言随着Flutter的广泛使用, 它终于变得越来越流行。健全性是飞镖语言的目标, 我们将对此进行讨论这里.

不健全以及TypeScript暴露严格类型导致的逃生舱口的各种方式使其效率降低, 不幸的是使它变得无效有总比没有好马上。我的愿望是, 随着TypeScript的流行, 更多的编译器选项可供使用, 从而使高级用户可以争取100%的可靠性。

TypeScript不保证任何运行时类型检查

运行时类型检查不是TypeScript的目标之一, 因此这种愿望可能永远不会实现。例如, 在处理从API调用返回的JSON有效负载时, 运行时类型检查将是有益的。如果我们可以在类型级别上进行控制, 则不需要一整类错误和许多单元测试。

我们无法在运行时保证任何事情, 因此可能会发生:

const getFullName = async (): string => {
  const person: AxiosResponse = await api();
  
  //response.name.fullName may result in undefined at runtime
  return response.name.fullName
}

有一些支持库, 例如信息, 这很好, 但可能意味着你必须复制模型。

恐惧的任何类型和严格性选项

的任何type就是这样, 编译器允许任何操作或赋值。

TypeScript可以很好地用于小事情, 但是人们倾向于任何输入任何需要一分钟以上的时间。我最近在Angular项目上工作, 看到了很多这样的代码:

export class Person {
 public _id: any;
 public name: any;
 public icon: any;

TypeScript让你忘记类型系统。

你可以使用任何投:

("oh my goodness" as any).ToFixed(1); // remember what I said about soundness?

的严格编译器选项可启用以下编译器设置, 这些设置会使事情变得更加响亮:

  • --strictNullChecks
  • --noImplicitAny
  • --noImplicitThis
  • -始终严格

还有陪同规则@ typescript-eslint / no-explicit-any.

的扩散任何会破坏你打字的声音。

总结

我必须重申, 我是TypeScript爱好者, 我在日常工作中使用它, 但是我确实认为它会很快出现, 而且炒作还不完全合理。 Airbnb声明TypeScript可以防止38%的错误。我非常怀疑这个精确的百分比。 TypeScript不会提高现有的良好做法。我仍然必须编写尽可能多的测试。你可能会争论, 我正在编写更多代码, 并且可能不得不编写类型测试。我仍然遇到意外的运行时错误。

TypeScript提供了以上基本的类型检查, 但是健全性和运行时类型检查不是目标, 这使TypeScript处于不幸的中途屋子, 一只脚在一个更好的世界中, 而我们目前在其中。

TypeScript的亮点在于具有良好的IDE支持, 例如vscode, 如果我们键入错误的内容, 我们将获得视觉反馈。

vscode中的打字稿错误

vscode中的TypeScript错误

使用TypeScript还可以增强重构, 并且在对修改后的代码运行TypeScript编译器时, 可以立即识别代码中断(例如方法签名的更改)。

TypeScript启用了良好的类型检查, 并且绝对比没有类型检查器或仅是普通的eslint更好, 但是我认为它可以做更多的事情, 而且对于那些我们想要更多的人来说, 可以提供足够的编译器选项。

日志火箭:全面了解你的网络应用

LogRocket仪表板免费试用横幅

日志火箭是一个前端应用程序监视解决方案, 可让你重播问题, 就好像问题发生在你自己的浏览器中一样。 notlogy无需猜测错误发生的原因, 也不要求用户提供屏幕截图和日志转储, 而是让你重播会话以快速了解出了什么问题。无论框架如何, 它都能与任何应用完美配合, 并具有用于记录来自Redux, Vuex和@ ngrx / store的其他上下文的插件。

除了记录Redux动作和状态外, notlogy还会记录控制台日志, JavaScript错误, 堆栈跟踪, 带有标题+正文, 浏览器元数据和自定义日志的网络请求/响应。它还使用DOM来记录页面上的HTML和CSS, 甚至可以为最复杂的单页面应用程序重新创建像素完美的视频。

免费试用

.

一盏木

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: