2024 年 TypeScript 编程中要改掉的 10 个糟糕习惯

TypeScript 已经成为许多开发者的首选语言，提供了静态类型的好处，同时保持了 JavaScript 的灵活性。然而，随着 TypeScript 的持续演进，曾经的最佳实践现在可能已经过时或不再是最优的选择。在这篇文章里，我们会讲到 你应该在 2024 年摒弃的 10 个不良 TypeScript 习惯，以便写出更清晰、更高效且更易于维护的代码。

1. 未启用strict模式

问题:

很多开发者关闭了 TypeScript 的 strict 模式以避免更严格的类型校验。

为什么不好：

如果去掉 strict 模式，TypeScript 会更宽松一些，降低了类型安全的保障。这可能导致意外的错误，并在未来使代码重构变得更复杂。

你应该做什么：

在你的 tsconfig.json 中启用 strict 模式。它将进行更严格的数据类型检查，并确保你的代码在长期中更加强大。

    {
      "compilerOptions": {
        "strict": true
      }
    }

启用严格模式以提高代码质量。

切换到全屏 | 退出全屏

zh: 此处省略若干文字

2. 过度依赖任何

问题：

在编程过程中，any 类型常被当作快速解决办法，当开发人员不想去想正确的类型是什么时。

为什么不好：

使用 any 违背了使用 TypeScript 的初衷，就相当于回到了 JavaScript。这可能导致运行时错误，因为 TypeScript 将无法再在开发过程中帮助捕捉错误。

你可以用什么代替？

使用更具体的数据类型，比如 未知，或者更好的做法是定义一个合适的数据类型。未知 类型比 任何 更安全，因为它会在使用数据前进行类型检查。

    let data: unknown;

    if (typeof data === "string") {
      console.log(data.toUpperCase());
    }

点击这里进入全屏模式，点击这里退出全屏模式

此处内容省略

3. 不小心使用类型断言可能会导致问题

问题就是：

类型断言（as 关键字）可以被过度使用，特别是在开发人员对类型不确定且希望消除 TypeScript 报错时。

为什么不好：

类型断言可能会导致不安全的代码，因为它们告诉 TypeScript 将一个值视为特定类型，即使实际上并不符合这个类型。如果该值不是你所期望的，这可能在运行时引发问题。

你可以这样做：

限制类型断言的使用。相反，使用类型守卫来安全地检查和推断类型，在使用之前。

    function isString(value: unknown): value 是字符串 {
      return typeof value === 'string';
    }

    if (isString(data)) {
      console.log(data.toUpperCase());
    }

切换到全屏 退出全屏

此处省略部分内容

4. 忽视联合和交集

问题：

有些开发者宁愿不使用联合（|）和交集（&），即使这会使代码更易读、更精确。

为什么这不好：

如果没有联合类型，你的代码可能会变得非常冗长，你可能就会错过 TypeScript 更简洁地描述复杂数据结构的能力。

可以做些什么：

使用联合类型和交集类型来构建更灵活和易于重用的类型定义。

    type 管理员 = { 是否管理员: true; 权限: string[] };
    type 用户 = { 是否管理员: false; email: string };

    type 人员 = 管理员 | 用户;

    function 记录用户信息(person: 人员) {
      if (person.是否管理员) {
        console.log(person.权限);
      } else {
        console.log(person.email);
      }
    }

全屏模式；退出

＊＊＊

5. 使用非特定的返回类型

问题如下：

函数的返回类型通常是非特定类型（如any、object），这就需要使用该函数的人自己判断应该期待什么样的返回结果。

为什么不好：

不确定的返回类型会使你的代码更难预测和调试和追踪。这会使你失去在TypeScript中的静态类型系统的好处，使你的代码更容易出现错误。

可以这样做：

始终要指定函数的具体返回类型。如果函数返回多种类型的话，则可以使用联合类型来描述这些类型。

// 获取数据的函数，返回一个包含 id 和 name 的 Promise
function 获取数据(): Promise<{ id: number; name: string }> {
  return fetch("/data").then(response => response.json());
}

全屏模式。退出全屏。

zh: 此处省略了内容

6. 别管null 和 未定义

问题来了:

一些开发人员在代码中忽视了 null 和 undefined 值，导致了意外的错误。

为什么不好：

JavaScript 中变量可以是 null 或 undefined，TypeScript 提供了处理这些值的工具来帮助开发者。忽略它们可能在尝试访问 null 或 undefined 的属性或调用它们的方法时引发运行时错误。

你可以这样做：

使用可选链操作符和空值合并运算符安全地处理这些 null 和 undefined 值。

const name = user?.profile?.name ?? "Guest"; // 如果用户有 profile 并且 profile 有 name，则获取 name；否则，默认为 "Guest"

全屏模式 退出全屏

zh: ……

7. 滥用Enums

看来看看这个问题：

Enums 常被用于简单的常量值，而其他类型如 const 或字面量联合体可能就已经足够了。

为什么它不好：

枚举可能会增加不必要的复杂性，特别是在有更简单的替代方案的情况下。在某些情况下，它们甚至可能引入与可变性相关的问题。

可以做什么：

使用字面量或 const 对象来定义简单的常量值。

    type 角色类型 = "Admin" | "User" | "Guest";

    let 用户身份: 角色类型 = "Admin";

全屏模式，退出全屏

zh: zh: 此处省略 （省略）

8. 未使用readonly属性。

问题:

未使用 readonly 关键字会导致数据结构可变，这可能引起错误和意想不到的副作用。

为什么这不好：坏处是：

这可能会导致对象或数组的意外更改，从而使得追踪错误变得更加困难。

可以这样做：

在合适的地方，使用 readonly 来确保不可变性。

    const data: readonly number[] = [1, 2, 3]; // 定义一个只读的数字数组

切换到全屏 退出全屏

---

9. 忽略自定义类型的检查

问题如下:

许多开发人员更依赖隐式的检查方法，而不是使用自定义类型守卫来确保类型的安全性。

为什么不好:

没有显式的类型断言，你可能在运行时错过某些类型，从而导致运行时错误。

可以试试这样做：

实现自定义类型守门员（type guards）以显式检查类型，让您的代码更可靠。

function isUser(user: any): user 是用户 {
  // 返回 user.email 是字符串类型
  return typeof user.email === "string";
}

全屏(按ESC退出)

---

10. 未使用未知类型

问题来了：

开发人员在最初不确定变量类型时，常常直接使用 any，这种情况。

为什么不好：

any 关闭类型检查，这实际上违背了使用 TypeScript 的本意。

可以试试这样做：

当您不确定变量的初始类型时，可以使用 unknown 类型，并根据需要逐步指定具体类型。

    让我们来解释一下这段代码：这段代码定义了一个未知类型的变量 `input`。然后它检查 `input` 是否为字符串类型。如果是字符串类型，它会将字符串转换为大写并打印出来。

    let input: unknown;

    if (typeof input === "string") {
      console.log(input.toUpperCase());
    }

进入全屏，退出全屏

---

最后的思考

在 2024 年打破这些不良的 TypeScript 习惯将帮助你编写更易维护、更高效且无错误的代码。通过采用更严格的类型检查，避免使用诸如 any 这样的捷径，并充分利用 TypeScript 的高级特性，你可以显著改善代码质量，成为更高效的开发者。

今天就到这里吧。

另外，分享你最喜欢的一些网页开发资源，帮助这里的新手们！

跟我联系:@ LinkedIn, 看看我的作品集，点击这里查看。

来看看我的 YouTube 频道，觉得有用的话。

请在我的GitHub项目上给个支持⭐️

谢谢你们！🤗