N'utilisez pas de types de types de types comme celui-ci. Utilisez plutôt le motif de la carte

Cette implémentation TypeScript présente un processus de refactorisation pour améliorer la flexibilité et la maintenabilité. Reformons-le pour la clarté et l'amélioration du flux.

Améliorer la flexibilité de typeScript avec le modèle de carte: une étude de cas

Au cours d'un projet récent, j'ai rencontré une implémentation de typeScript qui, bien que fonctionnelle, manquait de flexibilité. Ce message détaille le problème, sa solution à l'aide du modèle de carte et comment cette approche améliore la maintenabilité du code.

Table des matières

1. le problème initial
2. Limites de l'approche originale
3. Implémentation de la solution de modèle de carte
4. Implémentation du code propre
5. Application de la sécurité de type avec des réactions autorisées
6. Comparaison visuelle
7. Conclusion

1. Le problème initial

Le code d'origine a utilisé ces types de typeScript:

<code class="language-typescript">// Reaction.ts
export type Reaction = {
  count: number;
  percentage: number;
};

// FinalResponse.ts
import { Reaction } from './Reaction';

export type FinalResponse = {
  totalScore: number;
  headingsPenalty: number;
  sentencesPenalty: number;
  charactersPenalty: number;
  wordsPenalty: number;
  headings: string[];
  sentences: string[];
  words: string[];
  links: { href: string; text: string }[];
  exceeded: {
    exceededSentences: string[];
    repeatedWords: { word: string; count: number }[];
  };
  reactions: {
    likes: Reaction;
    unicorns: Reaction;
    explodingHeads: Reaction;
    raisedHands: Reaction;
    fire: Reaction;
  };
};</code>

Ce type FinalResponse a été utilisé dans une fonction de notation:

<code class="language-typescript">// calculator.ts
export const calculateScore = (
  // ... input parameters ...
  reactions: {
    likes: Reaction;
    unicorns: Reaction;
    explodingHeads: Reaction;
    raisedHands: Reaction;
    fire: Reaction;
  },
): FinalResponse => {
  // Score calculation logic...
};</code>

2. Limites de l'approche originale

L'ajout d'une nouvelle réaction a nécessité des modifications sur plusieurs fichiers (FinalResponse.ts, calculator.ts, et potentiellement d'autres). Ce couplage serré a augmenté le risque d'erreurs et a rendu le code moins maintenable.

3. Implémentation de la solution de modèle de carte

Pour résoudre ce problème, une approche plus dynamique utilisant une structure de type Map a été mise en œuvre:

<code class="language-typescript">// FinalResponse.ts
import { Reaction } from './Reaction';

type AllowedReactions =
  | 'likes'
  | 'unicorns'
  | 'explodingHeads'
  | 'raisedHands'
  | 'fire';

export type ReactionMap = {
  [key in AllowedReactions]: Reaction;
};

export type FinalResponse = {
  // ... other properties ...
  reactions: ReactionMap;
};</code>

4. Implémentation de code propre

La fonction calculateScore utilise désormais le ReactionMap:

<code class="language-typescript">// calculator.ts
export const calculateScore = (
  // ... input parameters ...
  reactions: ReactionMap,
): FinalResponse => {
  // Score calculation logic...
};</code>

5. Application de la sécurité de type avec des réactions autorisées

Bien que le ReactionMap offre une flexibilité, il est crucial de maintenir la sécurité du type. Le type d'union AllowedReactions restreint les clés de réaction autorisées, empêchant l'ajout de réactions arbitraires.

6. Comparaison visuelle

7. Conclusion

Cette approche refactorisée équilibre la flexibilité et la sécurité des types. L'ajout de nouvelles réactions nécessite uniquement la mise à jour du type AllowedReactions, améliorant considérablement la maintenabilité et réduisant le risque d'erreurs par rapport à la conception d'origine serrée. L'utilisation d'un type Record émule efficacement les avantages d'une carte sans les frais généraux d'exécution d'un objet Map.

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!