✨ Idées publicitaires en TypeScript-js tutoriel-php.cn

J'adore ❤️ TypeScript.

Surtout après avoir rencontré les fameuses erreurs "Impossible d'accéder à la valeur non définie" de JavaScript.

Cependant, même si TypeScript est génial, il existe encore des moyens de se tirer une balle dans le pied.

Dans cet article, je partagerai 5 mauvaises pratiques en TypeScript et comment les éviter.

? Téléchargez mon livre GRATUIT de 101 trucs et astuces React pour prendre une longueur d'avance.

✨ ad Ideas in TypeScript

1. Déclaration des erreurs de type Any

Exemple

Dans l'extrait de code suivant, nous captons l'erreur puis la déclarons comme type any.

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err: any) {
    toast(`Failed to do something: ${err.message}`);
  }
}

Copier après la connexion

Pourquoi c'est mauvais ❌

Il n'y a aucune garantie que l'erreur ait un champ de message de type chaîne.

Malheureusement, en raison de l'assertion de type, le code nous laisse supposer que c'est le cas.

Le code peut fonctionner en développement avec des cas de test spécifiques mais peut gravement échouer en production.

Que faire à la place ✅

Ne définissez pas le type d'erreur. Il devrait être inconnu par défaut.

Au lieu de cela, vous pouvez effectuer l'une des opérations suivantes :

Option 1 : Vérifiez si l'erreur est du bon type avec une protection de type.

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err) {
    const toastMessage = hasMessage(err)
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;
    toast(toastMessage);
  }
}

// We use a type guard to check first
function hasMessage(value: unknown): value is { message: string } {
  return (
    value != null &&
    typeof value === "object" &&
    "message" in value &&
    typeof value.message === "string"
  );
}

// You can also simply check if the error is an instance of Error
const toastMessage = err instanceof Error
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;

Copier après la connexion

Option 2 (recommandée) : Ne faites pas d'hypothèses sur l'erreur

Au lieu de faire des hypothèses sur le type d'erreur, gérez chaque type explicitement et fournissez des commentaires appropriés à l'utilisateur.

Si vous ne parvenez pas à déterminer le type d'erreur spécifique, il est préférable d'afficher des informations complètes sur l'erreur plutôt que des détails partiels.

Pour plus d'informations sur la gestion des erreurs, consultez cet excellent guide : Rédiger de meilleurs messages d'erreur.

✨ ad Ideas in TypeScript

2. Avoir des fonctions avec plusieurs paramètres consécutifs du même type

Exemple

export function greet(
  firstName: string,
  lastName: string,
  city: string,
  email: string
) {
  // Do something...
}

Copier après la connexion

Pourquoi c'est mauvais ❌

Vous pouvez accidentellement transmettre des paramètres dans le mauvais ordre :

// We inverted firstName and lastName, but TypeScript won't catch this
greet("Curry", "Stephen", "LA", "stephen.curry@gmail.com")

Copier après la connexion

Il est plus difficile de comprendre ce que représente chaque paramètre, notamment lors des revues de code, lorsqu'on voit l'appel de la fonction avant sa déclaration

Que faire à la place ✅

Utilisez un paramètre d'objet pour clarifier l'objectif de chaque champ et minimiser le risque d'erreurs.

export function greet(params: {
  firstName: string;
  lastName: string;
  city: string;
  email: string;
}) {
  // Do something...
}

Copier après la connexion

✨ ad Ideas in TypeScript

3. Avoir une fonction avec plusieurs branches et aucun type de retour

Exemple

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err: any) {
    toast(`Failed to do something: ${err.message}`);
  }
}

Copier après la connexion

Pourquoi c'est mauvais ❌

L'ajout d'un nouveau animalType pourrait conduire au retour d'un objet mal structuré.
Les modifications apportées à la structure du type de retour peuvent entraîner des problèmes difficiles à retracer dans d'autres parties du code.
Les fautes de frappe peuvent entraîner la déduction de types incorrects.

Que faire à la place ✅

Spécifiez explicitement le type de retour de la fonction :

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err) {
    const toastMessage = hasMessage(err)
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;
    toast(toastMessage);
  }
}

// We use a type guard to check first
function hasMessage(value: unknown): value is { message: string } {
  return (
    value != null &&
    typeof value === "object" &&
    "message" in value &&
    typeof value.message === "string"
  );
}

// You can also simply check if the error is an instance of Error
const toastMessage = err instanceof Error
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;

Copier après la connexion

✨ ad Ideas in TypeScript

4. Ajouter des types inutiles au lieu d'utiliser des champs facultatifs

Exemple

export function greet(
  firstName: string,
  lastName: string,
  city: string,
  email: string
) {
  // Do something...
}

Copier après la connexion

Pourquoi c'est mauvais ❌

N'évolue pas : l'ajout de nouveaux champs nécessite la création de plusieurs nouveaux types
Rend la vérification de type plus complexe, nécessitant des protections de type supplémentaires
Conduit à des noms de types confus et à une maintenance plus difficile

Que faire à la place ✅

Utilisez des champs facultatifs pour que vos types restent simples et maintenables :

// We inverted firstName and lastName, but TypeScript won't catch this
greet("Curry", "Stephen", "LA", "stephen.curry@gmail.com")

Copier après la connexion

✨ ad Ideas in TypeScript

5. Rendre les propriétés facultatives à différents niveaux de composants

Exemple

L'accessoire désactivé est facultatif dans tous les composants.

export function greet(params: {
  firstName: string;
  lastName: string;
  city: string;
  email: string;
}) {
  // Do something...
}

Copier après la connexion

Pourquoi c'est mauvais ❌

Facile d'oublier de transmettre l'accessoire désactivé, ce qui entraîne des formulaires partiellement activés

Que faire à la place ✅

Rendez les champs partagés obligatoires pour les composants internes.

Cela garantira un passage correct des accessoires. Ceci est particulièrement important pour les composants de niveau inférieur afin de détecter rapidement tout oubli.

Dans l'exemple ci-dessus, désactivé est désormais requis dans tous les composants internes.

function getAnimalDetails(animalType: "dog" | "cat" | "cow") {
  switch (animalType) {
    case "dog":
      return { name: "Dog", sound: "Woof" };
    case "cat":
      return { name: "Cat", sound: "Meow" };
    case "cow":
      return { name: "Cow", sound: "Moo" };
    default:
      // This ensures TypeScript catches unhandled cases
      ((_: never) => {})(animalType);
  }
}

Copier après la connexion

Remarque : Je ne le recommande pas si vous concevez des composants pour une bibliothèque, car les champs obligatoires demandent plus de travail.

✨ ad Ideas in TypeScript

Résumé

TypeScript est incroyable, mais aucun outil ?️ n'est parfait.

Éviter ces 5 erreurs vous aidera à écrire un code plus propre, plus sûr et plus maintenable.

Pour plus de conseils, consultez mon e-book gratuit, 101 trucs et astuces React.

? REPÉRER LE BUG

? CONSEIL DE LA SEMAINE

C'est fini ?.

Et n'oubliez pas de laisser un "???".

Si vous apprenez React, téléchargez mon livre 101 trucs et astuces React GRATUIT.

Si vous aimez les articles comme celui-ci, rejoignez ma newsletter GRATUIT, FrontendJoy.

Si vous voulez des conseils au quotidien, retrouvez-moi sur X/Twitter ou sur Bluesky.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!