Réponse.

TypeScript met en œuvre un mécanisme de vérification des propriétés excessives (Excess Property Checking) pour une sécurité supplémentaire, afin d'avertir le programmeur des erreurs dans les déclarations d'objets lorsque un littéral d'objet est directement assigné à une variable d'un certain type. Ce mécanisme est né du fait que la typage structurelle de TypeScript peut permettre des propriétés non déclarées additionnelles, ce qui conduit souvent à des erreurs dans la logique du programme, en particulier lors de l'utilisation d'API ou de formulaires.

Contexte historique

Les vérifications de propriétés excessives ont été introduites pour améliorer la sécurité du développement frontend, où la structure des objets suit souvent un modèle contractuel strict (par exemple, pour la sérialisation en JSON). Lorsque un objet est créé comme littéral et est immédiatement passé à une fonction ou stocké dans une variable d'un type défini, TS effectue une vérification "excessive" – il recherche des propriétés additionnelles qui ne sont pas décrites dans le type supposé.

Problème

Une erreur du programmeur peut passer inaperçue si l'objet contient une faute de frappe ou une propriété supplémentaire, et cette propriété ne sera pas utilisée correctement ou restera invisible pour la logique métier. De plus, les vérifications de propriétés excessives peuvent réagir de manière inattendue – par exemple, si un objet n'est pas explicitement typé ou est manipulé à l'aide d'opérateurs de propagation ou via des variables intermédiaires.

Solution

TypeScript applique les vérifications des propriétés excessives aux littéraux d'objet qui sont assignés directement à une variable ou un paramètre de fonction. La vérification examine toutes les propriétés de l'objet et les compare avec le type déclaré – s'il y a des propriétés supplémentaires, une erreur de compilation se produira.

interface UserProfile {
  name: string;
  age: number;
}

const user: UserProfile = {
  name: "Sam",
  age: 25,
  email: "sam@mail.com" // Erreur : propriété supplémentaire email
};

Pour contourner la vérification excessive, par exemple pour les objets avec des propriétés dynamiques ou une typage partielle, des signatures d'index ou des variables intermédiaires sont utilisées.

interface FlexibleUser {
  name: string;
  [prop: string]: any; // La signature d'index permet toutes nouvelles propriétés
}

const user2: FlexibleUser = {
  name: "Sam",
  age: 25,
  email: "sam@mail.com" // Fonctionne correctement
};

Caractéristiques clés :

Les vérifications des propriétés excessives ne s'appliquent qu'aux littéraux d'objet assignés à une variable typée explicitement.
Les vérifications peuvent être contournées à l'aide d'une signature d'index ou d'une assignation via une variable intermédiaire.
Protège contre les fautes de frappe triviales et les erreurs dans la structure des données.

Questions pièges.

Si vous créez un objet avec une propriété supplémentaire, l'assignez à une variable sans type, puis après changez le type, la vérification des propriétés excessives se produira-t-elle ?

Non, la vérification excessive fonctionne uniquement lors de l'assignation directe d'un littéral. Si l'objet est créé à l'avance et que le type est ensuite spécifié, les propriétés supplémentaires ne sont pas détectées.

const temp = {
  name: "John",
  age: 18,
  foo: "bar"
};
const u: UserProfile = temp; // Pas d'erreur, foo est ignoré

Les vérifications des propriétés excessives fonctionnent-elles pour les classes et les instances de classes ?

Non, cette vérification n'est pas effectuée pour les classes et les instances de classes, uniquement pour les littéraux d'objets.

Peut-on désactiver les vérifications excessives de manière globale dans les paramètres TS ?

Non, il n'y a pas de paramètre séparé pour désactiver cela. Cependant, on peut définir une signature d'index pour les propriétés ou utiliser l'opérateur d'assertion de type ('as') pour indiquer explicitement qu'aucune vérification n'est nécessaire.

const special: UserProfile = {
  name: "Max",
  age: 22,
  hobby: "js"
} as UserProfile;

Erreurs typiques et anti-patterns

Utiliser une assertion de type pour désactiver la vérification (cela peut conduire à des erreurs manquées dans la structure des objets).
Utiliser de manière injustifiée une signature d'index compromet la rigueur de la description du type.

Exemple concret

Cas négatif

Un développeur crée une interface pour un formulaire utilisateur, permettant toutes les propriétés via [key: string]: any, pour éviter des erreurs avec des champs supplémentaires.

Avantages : Pas d'erreurs de compilation avec des données dynamiques.

Inconvénients : Aucune des erreurs de structure du formulaire ou des fautes de frappe n'est détectée, difficile d'identifier des bugs.

Cas positif

Un développeur définit une interface stricte et utilise une fonction séparée pour transformer des données dynamiques en une structure stricte, avec une validation préalable.

Avantages : L'interface correspond toujours au contrat attendu, le compilateur détecte les fautes de frappe, maintenabilité élevée.

Inconvénients : Nécessité d'écrire du code supplémentaire pour la vérification et le mappage des données dynamiques.