Les types utilitaires

La tentation du copier-coller de types

Imaginons une interface Article avec quatre champs : id, titre, contenu, brouillon. Tu dois écrire une fonction de mise à jour partielle, le genre qui n'accepte que les champs qu'on veut modifier. La tentation est immédiate : copier l'interface, coller, ajouter des ? partout.

interface Article {
  id: number;
  titre: string;
  contenu: string;
  brouillon: boolean;
}

// La tentation : copier-coller et tout rendre optionnel
interface ArticlePartiel {
  id?: number;
  titre?: string;
  contenu?: string;
  brouillon?: boolean;
}

Deux semaines après, on ajoute un champ auteur à Article. La copie ne le sait pas. Elle diverge en silence. La fonction de mise à jour accepte { auteur: 'Bob' } en JavaScript mais TS ne voit pas le problème dans ArticlePartiel : le champ n'y est pas. Le bug s'installe doucement, porté par une copie qu'on avait oubliée.

Transformer au lieu de réécrire

Les types utilitaires sont des génériques (leçon 6) fournis par TypeScript qui fabriquent un type à partir d'un autre. La source de vérité reste une seule interface : toutes les variantes en dérivent et suivent ses évolutions automatiquement.

interface Article {
  id: number;
  titre: string;
  contenu: string;
  brouillon: boolean;
}

// Tous les champs deviennent optionnels : parfait pour une mise à jour partielle
type ArticlePartiel = Partial<Article>;

// Garder uniquement id et titre : idéal pour un résumé ou une liste
type ArticleResume = Pick<Article, 'id' | 'titre'>;

// Tout sauf contenu : par exemple pour un aperçu sans le corps
type ArticleSansCorps = Omit<Article, 'contenu'>;

// Dictionnaire : clé string, valeur number (compteur de vues par slug)
type VuesParSlug = Record<string, number>;

// Tous les champs en lecture seule : immuable après création
type ArticleFige = Readonly<Article>;

Un exemple concret par utilitaire, une ligne chacun. Ajoute auteur: string à Article : ArticlePartiel, ArticleResume, ArticleSansCorps et ArticleFige le voient immédiatement. Zéro mise à jour manuelle, zéro divergence.

À toi : Partial piège la faute de frappe

Partial<Article> accepte un sous-ensemble des champs, mais pas un champ qui n'existe pas : la faute de frappe dans une mise à jour partielle, classique en JavaScript, est morte ici aussi.

Le réflexe : cherche l'utilitaire avant de réécrire

À chaque fois que tu t'apprêtes à écrire un type « presque pareil » à un autre, pause. La question à se poser : est-ce que je veux rendre des champs optionnels, garder certains champs, en enlever quelques-uns, ou décrire un dictionnaire ? Si oui, il y a un utilitaire pour ça.

Composer les utilitaires : extends ou & ?

Les utilitaires se combinent. Un formulaire de création d'article partiellement prérempli ? C'est Partial<Article> plus un champ obligatoire en plus — deux types à fusionner.

// Fusionner avec &
type BrouillonForcé = Partial<Article> & { brouillon: true }

// Même résultat avec extends
interface BrouillonForcé extends Partial<Article> {
  brouillon: true
}

Dans ce cas, les deux sont équivalents. La différence apparaît sur un conflit de propriété :

interface A { id: string }
interface B { id: number }

interface C extends A, B {}    // ❌ Erreur à la déclaration
                               //    Types of property 'id' are incompatible

type C = A & B                 // ✅ Aucune erreur à la déclaration…
const c: C = { id: ??? }       // ❌ …mais id vaut string & number = never
                               //    Aucune valeur possible