TypeScript之为什么停止使用any

这篇文章主要介绍“TypeScript之为什么停止使用any”，在日常操作中，相信很多人在TypeScript之为什么停止使用any问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”TypeScript之为什么停止使用any”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

什么是 any

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

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

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

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

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

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

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

(2) 有些参数很难正确输入，但是 any 更容易

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

(3) 我真的不知道参数是什么

没关系!我们可以用 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"   } }

(4) 添加类型时，我必须编写大量代码，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}`; }

(5) 类型增加了很多复杂性，有时any更简单

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

(6) 有了文档，我可以提供所有上下文

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

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

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

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

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

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

我们总是可以修改和适应新的类型定义， 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 ) => {   {...} }

(9) 很好，从TypeScript中删除 any，立即打开PR

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

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

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

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

到此，关于“TypeScript之为什么停止使用any”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！