查看原文
其他

TypeScript: 请停止使用 any

前端大全 2021-02-08

The following article is from code秘密花园 Author ConardLi 译

(给前端大全加星标,提升前端技能

作者:code秘密花园 公号 / ConardLi 译

本文译自:https://thoughtbot.com/blog/typescript-stop-using-any-there-s-a-type-for-that

当我们开发 TypeScript 代码时,很可能会遇到 any 关键字。我们看到的大多数用法都表明我们正在处理 TypeScript 中的基本类型。在文档中我们可能会找到:

(…)来不使用 TypeScript 或第3方库编写的代码的值。在这些情况下,我们可能要选择退出类型检查。为此,我们将这些值标记为 any 类型:

什么是 any

因此 any 不是通配符,也不是基类型,它是明确地与第三方库进行交互。那它为什么经常出现你呢?它对我们的系统有害吗?我们应该逃避它还是拥抱它?

any 类型是使用现有 JavaScript 的强大方法,可让您在编译期间逐渐选择加入和选择退出类型检查。

TypeScript 文档明确表达了当我们使用any类型时,我们正在告诉编译器:

当超过500名该语言的贡献者提供帮助时,我们说 no thank you。这听起来像是选择退出类型检查器,有了它,就不能轻易地放弃对类型系统的所有安全性和信心。我们应该使用它来与无类型的第三方(或第一方) Javascript 代码交互,或者当我们只知道类型的一部分时。

但是等等我还有很多其他原因

TypeScript 不会转换为 Javascript 吗?Javascript 不是动态的吗?那我为什么要考虑我的类型呢?

是的!但是我们用 TypeScript 写代码,这是一种静态类型语言。有人可能会说静态类型语言不会比动态语言产生更少的 bug 。不过,在使用 any 之类的静态类型语言中,这是两种情况中最糟糕的。

有些参数很难正确输入,但是 any 更容易

如果我们没有正确地输入,我们将会编写错误,比我们在动态语言中会编写更多的错误,因为我们强制 TypeScript ,一种静态类型语言,去检查不正确的类型。

我真的不知道参数是什么

没关系!我们可以用 unknown ; 它允许我们确实分配任何类型。但在确定特定类型之前,我们将不允许使用这些值。

type ParsedType = {
  id: number
}

const parseApiResponse(
  response: Record<string, unknown>
): ParsedType => {
  const convertedResponse = (response as ParsedType)

  // without doing the type cast we would
  // get a type error here
  if(convertedResponse.id >= 0) {
    return convertedResponse
  } else {
    throw Error.new("Invalid response"
  }
}

添加类型时,我必须编写大量代码,any工作量较少

可能不是,如果编写的代码没有类型,则我们可能需要添加防御性代码,以确保参数和变量具有正确的类型,以使程序能够按预期执行。any 甚至无法防范 null 或 undefined 检查我们的逻辑 。

// version 1 with `any`
const fullName = (user: any) => {
  if (user?.firstName && user?.lastName) {
    return `${user.lastName}, ${user.firstName}`
  }

  return user?.firstName || ""
}

// version 1 without `any`

interface User {
  firstName: string
  lastName?: string
}

const fullName = ({ firstName, lastName }: User) => {
  if (lastName === undefined) {
    return firstName
  }

  return `${lastName}, ${firstName}`;
}

类型增加了很多复杂性,有时any更简单

使用 any 可能允许我们在不考虑数据如何流入逻辑的情况下更简单的开发。但它将这个负担会转移到我们代码的未来读者身上。他们将不得不在没有上下文和编译器帮助的情况下解释发生了什么。

有了文档,我可以提供所有上下文

添加类型时,我们会从编译器获得帮助,并且会获得不会随时间推移而衰减的文档,因为如果过时了,我们的代码将无法编译。

const intersection = (a: any, b: any): any => {
...
}
const intersection = (
  a: Set<number>, bSet<number>
): Set<number> => {
...
}

它们都是等效的,但是读者会更好地了解后面的函数在做什么,而不是从第一个函数开始。

我已经通过必要的运行时检查以防御性的方式编写了代码,以确保没有错误

现在可能没有错误,但是除非你有很好的测试覆盖率,否则以后来修改代码的人不会相信他们不是在错误中重构;就好像编译器不会帮你,因为我们说过它不会帮你。如果我们显式地设置类型并更改系统中使用的API,编译器将提供它的指导。

如果以后我改变主意怎么办?我可能会为此重构几个小时

我们总是可以修改和适应新的类型定义, TypeScript 为此提供了一组实用功能。我们可以 Pick 习惯从先前定义的类型中选择所需的属性。Omit 得到除少数几个以外的所有东西。Partial 使所有属性都是可选的,或进行完整的180并使其全部Requireds。

type User = {
  id: number;
  firstName: string;
  lastName: string;
  age: number;
}

type UserParams =
  Pick<User, "id"> & Partial<Omit<User, "id">>

const updateUser = (
  { id, ...newUserParams }: UserParams
) => {
  {...}
}

很好,从TypeScript中删除 any,立即打开PR

让我们深吸一口气, any 它在正确的情况下非常强大且有用。

  • 与使用它的库接口;确保在将数据移至系统之前尽快将其转换为正确的类型。

  • 解决 TypeScript 类型错误;如果我们发现自己无法输入某些内容,则 any 可能有必要。但是只有在尝试其他所有方法之后才推荐使用。如果使用它,我们应该将其重新转换为可预测的类型。

  • 如果我们的函数可以真正处理任何类型,那么这种情况很少见,并且是偶然的(例如调试或日志记录函数)。在这些情况下,我们需要 100% 确保不存在会导致函数失败的类型。我们应该检查函数的主体,并根据输入确定最基本的形状并加以限制。例如,如果我们要打印某些内容,则至少应验证它是否响应 toString 。

让我们回顾一下

为什么我们不能在使用 any ?

  • 它使编译器过时了,我们告诉编译器:我不需要你的帮助
  • 我们放弃了在编写代码时记录代码的机会
  • 我们的第一道防线被攻破了
  • 在动态语言中,我们假设事物可以有 any 类型,我们采用的模式遵循这个假设。如果我们开始使用静态类型语言作为动态语言,那么我们就是在与范式作斗争
  • 当我们继续对代码库进行更改时,没有什么可以指导/帮助我们。
  • 自由越大,责任越大(编译器)。不要变成一个编译器,我们的目的是使用编译器。


推荐阅读  点击标题可跳转

1、TypeScript之父:JS不是竞争对手

2、重新认识Typescript | Vue3源码系列

3、TypeScript 4.0 来了,有什么新的关注点?


觉得本文对你有帮助?请分享给更多人

关注「前端大全」加星标,提升前端技能

点赞和在看就是最大的支持❤️

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存