ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

2022 年要改掉的 10 个 TypeScript 坏习惯

2022-09-05 08:31:12  阅读:221  来源: 互联网

标签:10 TypeScript 为什么 代码 检查 2022 类型 应该 我们


2022 年要改掉的 10 个 TypeScript 坏习惯

TypeScript 和 JavaScript 在过去几年中不断进步,我们在过去几十年中建立的一些实践已经过时。有些可能永远没有意义。下面列出了我们都应该改掉的 10 个习惯。

1.不要使用严格模式

它看起来像什么

通过使用没有严格模式的 tsconfig.json。

它应该是什么样子

使用严格模式后。

我们为什么这样做

在代码库中引入更严格的规则通常需要时间。

为什么我们不应该

更严格的规则可以在未来更容易地更改代码,因此修复代码所花费的时间会被退回,之后在未来处理存储库时会花费一些时间。

2. 用 || 确定默认值

它看起来像什么

与||转身对于可选值:

它应该是什么样子

去买新的??运算符,或者更好的是,在参数级别定义折返权。

我们为什么这样做

这 ??运算符去年才被引入,如果在长函数的中间使用值,可能很难将它们定义为参数默认值。

为什么我们不应该

?? 与 || 不同,它只返回 null 或 undefined,而不是所有 falsy 值。此外,如果您的函数很长以至于您无法在一开始就定义默认值,那么将它们分开可能是个好主意。

3.使用any作为类型

它看起来像什么

当我们不确定结构时,应该使用任何类型的数据。

它应该是什么样子

在几乎所有我们键入任何内容的情况下,我们都应该将其键入为未知。

我们为什么这样做

any 很简单,因为它从根本上禁用了所有类型检查。通常,即使在官方类型中也使用 any(例如,上面示例中的 response.json() 被键入为 Promise由 TypeScript 团队提供)。

为什么我们不应该

它从根本上禁用所有类型检查。通过 any 进入的所有内容都将完全放弃任何类型检查。这可能会变得非常难以捕捉错误,因为只有当我们对类型结构的假设符合运行时代码时,代码才会失败。

4. val 作为 SomeType

它看起来像什么

强制告诉编译器它无法推断的类型。

它应该是什么样子

这就是类型守卫的用途。

我们为什么这样做

当我们想要从 JavaScript 转换为 TypeScript 时,现有的代码库经常对 TypeScript 编译器无法自动得出的类型做出假设。在这些情况下,使用快速 as SomeOtherType 可以加快转换速度,而无需放松 tsconfig 中的设置。

为什么我们不应该

即使现在可以保存断言,但当有人移动代码时,这可能会改变。类型保护将确保所有检查都是明确的。

5. 和任何测试一样

它看起来像什么

在编写测试时,它会创建不完整的替身。

它应该是什么样子

如果您需要为您的测试模拟数据,请将模拟逻辑移动到您模拟的事物旁边并使其可重用。

我们为什么这样做

虽然在尚未有很好的测试覆盖率的代码库中编写测试时,经常会出现复杂的大数据结构,但测试中的特定功能只需要其中的一部分。短期内无需担心其他属性更简单。

为什么我们不应该

放弃模拟的开发会咬我们一口,最近一次是当其中一个属性发生变化时,我们必须在所有测试中更改它而不是一个中心位置。此外,在某些情况下,被测代码依赖于我们之前认为不重要的属性,然后必须更新该功能的所有测试。

6. 可选属性

它看起来像什么

将属性定义为有时存在有时不存在的可选属性。

它应该是什么样子

清楚地表达,模型哪些组合存在,哪些不存在。

我们为什么这样做

将属性定义为可选而不是划分类型更容易并且生成的代码更少。它还需要对正在开发的产品有充分的了解,并且可以在对产品的假设发生变化时限制代码的使用。

为什么我们不应该

类型系统的最大好处是它们可以用编译时检查代替运行时检查。使用更快速的类型,可以在编译时检查可能会被忽视的错误,例如通过确保每个 DigitalProduct 都有一个 sizeInMb。

7. 一个字母泛型

它看起来像什么

用一个字母给名称一个通用名称

它应该是什么样子

应该给出一个完整的描述性类型名称。

我们为什么这样做

我猜这种习惯会养成,因为即使是官方文档也使用一个字母的名称。按 T​​ 代替写全名可以更快地键入,并且不需要考虑太多。

为什么我们不应该

泛型类型变量是变量,就像其他变量一样。当 IDE 开始向我们展示这些技术性时,我们已经放弃了在变量名称中描述变量技术性的想法。例如。我们通常只写 const name = 'Daniel' 而不是 const strName = 'Daniel'。此外,一个字母的变量名称通常会让人大吃一惊,因为如果不查看它们的声明,可能很难翻译它们的含义。

8.非布尔布尔检查

它看起来像什么

通过将值直接传递给 if 语句来检查值是否已定义。

它应该是什么样子

我们可以明确检查我们关心的情况。

我们为什么这样做

用简短的方式编写检查看起来更简洁,并且可以让我们避免思考我们真正想要检查的内容。

为什么我们不应该

也许我们应该考虑一下我们真正想要检查的内容。例如,上面给出的示例以不同的方式处理 countOfNewMessages 为 0 的情况。

9. Bang Bang 算子

它看起来像什么

将非布尔值转换为布尔值。

它应该是什么样子

明确检查我们关心的状况。

我们为什么这样做

对我们中的一些人来说,理解!就像开始对 JavaScript 宇宙的仪式一样。它看起来简短而简洁,如果您已经熟悉它,那么您就会知道它是关于什么的。这是将任何值转换为布尔值的简便方法。尤其是在代码库中,如果 null、undefined 和 '' 等虚假值之间没有明确的语义分离。

为什么我们不应该

像许多捷径和启动仪式一样,使用 !!通过宣传内部知识来混淆代码的真正含义。这使得新开发人员更不容易访问代码库,无论是一般开发的新手,还是 JavaScript 的新手。引入细微的错误也很容易。来自“非布尔布尔检查”的 countOfNewMessages 为 0 的问题仍然存在 !!。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明

本文链接:https://www.qanswer.top/15338/18410508

标签:10,TypeScript,为什么,代码,检查,2022,类型,应该,我们
来源: https://www.cnblogs.com/amboke/p/16656782.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有