10 mauvaises habitudes à rompre lorsque vous écrivez du code en TypeScript-js tutoriel-php.cn

10 mauvaises habitudes à rompre lorsque vous écrivez du code en TypeScript

TypeScript et JavaScript se développent régulièrement ces dernières années. Nous avons développé certaines habitudes dans le passé lors de l'écriture de code, et certaines d'entre elles n'ont tout simplement pas de sens. Voici 10 mauvaises habitudes dont nous devrions tous nous débarrasser.

1. Ne pas utiliser le mode `strict`

À quoi ressemble cette habitude

Ce n'est pas nécessaire ? être strict dans l'écriture de modèles tsconfig.json.

{
  "compilerOptions": {
    "target": "ES2015",
    "module": "commonjs"
  }
}

Copier après la connexion

Que faire

Activez simplement le mode strict :

{
  "compilerOptions": {
    "target": "ES2015",
    "module": "commonjs",
    "strict": true
  }
}

Copier après la connexion

Pourquoi est-ce une mauvaise habitude

Introduire des règles plus strictes dans une base de code existante prend du temps.

Pourquoi vous ne devriez pas le faire

Des règles plus strictes faciliteront la maintenance de votre code à l'avenir, vous faisant gagner beaucoup de temps.

2. Utilisez `||` pour définir les valeurs par défaut

À quoi ressemble cette habitude

Utiliser ? l'ancien Le || gère les valeurs par défaut de secours :

function createBlogPost (text: string, author: string, date?: Date) {
  return {
    text: text,
    author: author,
    date: date || new Date()
  }
}

Copier après la connexion

doit être effectué en utilisant le nouvel opérateur ou en redéfinissant la valeur par défaut dans l'argument.

function createBlogPost (text: string, author: string, date: Date = new Date())
  return {
    text: text,
    author: author,
    date: date
  }
}

Copier après la connexion

??Pourquoi est-ce une mauvaise habitude ?

L'opérateur n'a été introduit que l'année dernière et lors de l'utilisation de valeurs dans des fonctions longues, il peut être difficile de Il est défini sur la valeur par défaut du paramètre.

??Pourquoi vous ne devriez pas le faire

Contrairement à

est uniquement pour ?? ou || et ne s'applique pas à chacun une valeur virtuelle. ??nullundefined3. N'hésitez pas à utiliser des

types

`any`À quoi ressemble cette habitude

Quand vous ne le faites pas Lors de la détermination de la structure, vous pouvez utiliser le type .

async function loadProducts(): Promise<Product[]> {
  const response = await fetch(&#39;https://api.mysite.com/products&#39;)
  const products: any = await response.json()
  return products
}

Copier après la connexion

anyQue faut-il faire

Changez n'importe quel endroit de votre code qui utilise par

async function loadProducts(): Promise<Product[]> {
  const response = await fetch(&#39;https://api.mysite.com/products&#39;)
  const products: unknown = await response.json()
  return products as Product[]
}

Copier après la connexion

anyunknownPourquoi c'est pratique d'avoir cette mauvaise habitude de

car elle désactive fondamentalement toute vérification de type. Souvent,

est utilisé même dans les types officiellement fournis. Par exemple, l'équipe TypeScript a défini le type de

dans l'exemple ci-dessus sur any. anyresponse.json()Promise <any>Pourquoi vous ne devriez pas faire cela

Cela désactive essentiellement toute vérification de type. Tout ce qui arrive via abandonnera complètement toute vérification de type. Cela rendra les erreurs difficiles à détecter.

any4.

`val as SomeType`À quoi ressemble cette habitude

Dire de force au compilateur qu'il ne peut pas déduire ? taper.

async function loadProducts(): Promise<Product[]> {
  const response = await fetch(&#39;https://api.mysite.com/products&#39;)
  const products: unknown = await response.json()
  return products as Product[]
}

Copier après la connexion

Comment ça devrait être

C'est là que entre en jeu.

function isArrayOfProducts (obj: unknown): obj is Product[] {
  return Array.isArray(obj) && obj.every(isProduct)
}

function isProduct (obj: unknown): obj is Product {
  return obj != null
    && typeof (obj as Product).id === &#39;string&#39;
}

async function loadProducts(): Promise<Product[]> {
  const response = await fetch(&#39;https://api.mysite.com/products&#39;)
  const products: unknown = await response.json()
  if (!isArrayOfProducts(products)) {
    throw new TypeError(&#39;Received malformed products API response&#39;)
  }
  return products
}

Copier après la connexion

Type GuardPourquoi est-ce une mauvaise habitude ?

Lors du passage de JavaScript à TypeScript, les bases de code existantes ont souvent des types que le compilateur TypeScript ne peut pas automatiquement déduire. À ce stade, peut être utilisé pour accélérer la conversion sans avoir à modifier les paramètres dans

as SomeOtherTypetsconfigPourquoi vous ne devriez pas faire cela

garantira que tous les contrôles sont explicites.

Type Guard5.

`as any`À quoi ressemble cette habitude dans les tests

Lors de l'écriture de tests Créer une utilisation incomplète ? cas.

interface User {
  id: string
  firstName: string
  lastName: string
  email: string
}

test(&#39;createEmailText returns text that greats the user by first name&#39;, () => {
  const user: User = {
    firstName: &#39;John&#39;
  } as any
  
  expect(createEmailText(user)).toContain(user.firstName)
}

Copier après la connexion

Que faut-il faire

Si vous avez besoin de simuler des données de test, déplacez la logique de simulation à côté de l'objet que vous souhaitez simuler et rendez-la réutilisable.

interface User {
  id: string
  firstName: string
  lastName: string
  email: string
}

class MockUser implements User {
  id = &#39;id&#39;
  firstName = &#39;John&#39;
  lastName = &#39;Doe&#39;
  email = &#39;john@doe.com&#39;
}

test(&#39;createEmailText returns text that greats the user by first name&#39;, () => {
  const user = new MockUser()

  expect(createEmailText(user)).toContain(user.firstName)
}

Copier après la connexion

Pourquoi est-ce une mauvaise habitude ?

Lors de l'écriture de tests pour du code qui n'a pas encore une couverture de test étendue, il existe souvent des structures Big Data complexes, mais seulement. certains d'entre eux sont nécessaires pour la fonctionnalité spécifique que vous souhaitez tester. Ne vous inquiétez pas des autres attributs à court terme.

Pourquoi vous ne devriez pas faire cela

Dans certains cas, le code testé dépend d'une propriété que nous pensions auparavant sans importance, puis de toutes les fonctionnalités qui ciblez cette fonctionnalité qui doit être mise à jour en test.

6. Attributs facultatifs

À quoi ressemble cette habitude

Marquer les attributs comme propriétés facultatives, même si ces propriétés parfois n'existent pas.

interface Product {
  id: string
  type: &#39;digital&#39; | &#39;physical&#39;
  weightInKg?: number
  sizeInMb?: number
}

Copier après la connexion

Comment

devrait-il clarifier quelles combinaisons existent et lesquelles n'existent pas.

interface Product {
  id: string
  type: &#39;digital&#39; | &#39;physical&#39;
}

interface DigitalProduct extends Product {
  type: &#39;digital&#39;
  sizeInMb: number
}

interface PhysicalProduct extends Product {
  type: &#39;physical&#39;
  weightInKg: number
}

Copier après la connexion

Pourquoi est-ce une mauvaise habitude ?

Marquer les propriétés comme facultatives au lieu de diviser les types est plus facile et produit moins de code. Cela nécessite également une compréhension plus approfondie du produit en cours de construction et peut limiter l'utilisation du code si des modifications sont apportées à la conception du produit.

Pourquoi vous ne devriez pas faire cela

Le plus grand avantage du système de types est que vous pouvez utiliser des vérifications au moment de la compilation au lieu des vérifications au moment de l'exécution. Un typage plus explicite permet de vérifier au moment de la compilation les erreurs qui pourraient passer inaperçues, par exemple s'assurer que chaque a un

7. 用一个字母通行天下

这种习惯看起来是什么样的

用一个字母命名泛型

function head<T> (arr: T[]): T | undefined {
  return arr[0]
}

Copier après la connexion

应该怎样

提供完整的描述性类型名称。

function head<Element> (arr: Element[]): Element | undefined {
  return arr[0]
}

Copier après la connexion

为什么会有这种坏习惯

这种写法最早来源于C++的范型库，即使是 TS 的官方文档也在用一个字母的名称。它也可以更快地输入，只需要简单的敲下一个字母 T 就可以代替写全名。

为什么不该这样做

通用类型变量也是变量，就像其他变量一样。当 IDE 开始向我们展示变量的类型细节时，我们已经慢慢放弃了用它们的名称描述来变量类型的想法。例如我们现在写代码用 const name ='Daniel'，而不是 const strName ='Daniel'。同样，一个字母的变量名通常会令人费解，因为不看声明就很难理解它们的含义。

8. 对非布尔类型的值进行布尔检查

这种习惯看起来是什么样的

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

function createNewMessagesResponse (countOfNewMessages?: number) {
  if (countOfNewMessages) {
    return `You have ${countOfNewMessages} new messages`
  }
  return &#39;Error: Could not retrieve number of new messages&#39;
}

Copier après la connexion

应该怎样

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

function createNewMessagesResponse (countOfNewMessages?: number) {
  if (countOfNewMessages !== undefined) {
    return `You have ${countOfNewMessages} new messages`
  }
  return &#39;Error: Could not retrieve number of new messages&#39;
}

Copier après la connexion

为什么会有这种坏习惯

编写简短的检测代码看起来更加简洁，使我们能够避免思考实际想要检测的内容。

为什么不该这样做

也许我们应该考虑一下实际要检查的内容。例如上面的例子以不同的方式处理 countOfNewMessages 为 0 的情况。

9. ”棒棒“运算符

这种习惯看起来是什么样的

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

function createNewMessagesResponse (countOfNewMessages?: number) {
  if (!!countOfNewMessages) {
    return `You have ${countOfNewMessages} new messages`
  }
  return &#39;Error: Could not retrieve number of new messages&#39;
}

Copier après la connexion

应该怎样

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

function createNewMessagesResponse (countOfNewMessages?: number) {
  if (countOfNewMessages !== undefined) {
    return `You have ${countOfNewMessages} new messages`
  }
  return &#39;Error: Could not retrieve number of new messages&#39;
}

Copier après la connexion

为什么会有这种坏习惯

对某些人而言，理解 !! 就像是进入 JavaScript 世界的入门仪式。它看起来简短而简洁，如果你对它已经非常习惯了，就会知道它的含义。这是将任意值转换为布尔值的便捷方式。尤其是在如果虚值之间没有明确的语义界限时，例如 null、undefined 和 ''。

为什么不该这样做

与很多编码时的便捷方式一样，使用 !! 实际上是混淆了代码的真实含义。这使得新开发人员很难理解代码，无论是对一般开发人员来说还是对 JavaScript 来说都是新手。也很容易引入细微的错误。在对“非布尔类型的值”进行布尔检查时 countOfNewMessages 为 0 的问题在使用 !! 时仍然会存在。

10. `!= null`

这种习惯看起来是什么样的

棒棒运算符的小弟 ! = null使我们能同时检查 null 和 undefined。

function createNewMessagesResponse (countOfNewMessages?: number) {
  if (countOfNewMessages != null) {
    return `You have ${countOfNewMessages} new messages`
  }
  return &#39;Error: Could not retrieve number of new messages&#39;
}

Copier après la connexion

应该怎样

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

function createNewMessagesResponse (countOfNewMessages?: number) {
  if (countOfNewMessages !== undefined) {
    return `You have ${countOfNewMessages} new messages`
  }
  return &#39;Error: Could not retrieve number of new messages&#39;
}

Copier après la connexion

为什么会有这种坏习惯

如果你的代码在 null 和 undefined 之间没有明显的区别，那么 != null 有助于简化对这两种可能性的检查。

为什么不该这样做

尽管 null 在 JavaScript早期很麻烦，但 TypeScript 处于 strict 模式时，它却可以成为这种语言中宝贵的工具。一种常见模式是将 null 值定义为不存在的事物，将 undefined 定义为未知的事物，例如 user.firstName === null 可能意味着用户实际上没有名字，而 user.firstName === undefined 只是意味着我们尚未询问该用户（而 user.firstName === 的意思是字面意思是 '' 。