Antwoord.

TypeScript implementeert het mechanisme van Excess Property Checking voor extra veiligheid, om programmeurs te waarschuwen voor fouten in objectverklaringen wanneer een objectliteratuur direct aan een variabele van een type wordt toegewezen. Het mechanisme is ontstaan omdat de structurele typisering van TypeScript extra, niet-verklaarde eigenschappen kan toestaan, wat vaak tot logische fouten in het programma leidt, vooral bij het werken met API's of formulieren.

Achtergrond van de vraag

Excess Property Checks werden geïntroduceerd om de veiligheid van frontend-ontwikkeling te verbeteren, waar de structuur van objecten vaak een strikt contractmodel volgt (bijvoorbeeld voor serialisatie naar JSON). Wanneer een object als literatuur wordt gemaakt en direct aan een functie wordt doorgegeven of in een variabele van een bepaald type wordt opgeslagen, voert TS een "extra" controle uit — het zoekt naar extra eigenschappen die niet in het verwachte type zijn beschreven.

Probleem

Een programmeur kan een fout maken die onopgemerkt blijft als het object een typfout of een extra eigenschap bevat, en die eigenschap zal niet goed worden gebruikt of helemaal onzichtbaar blijven voor de bedrijfslogica. Bovendien kunnen Excess Property Checks onverwacht worden geactiveerd — bijvoorbeeld als het object niet expliciet is getypeerd of wordt verwerkt met behulp van spread-operators of tussenvariabelen.

Oplossing

TypeScript past Excess Property Checks toe op objectliteraturen die direct aan een variabele of functieparameter worden toegewezen. De controle zoekt naar alle eigenschappen van het object en vergelijkt deze met het verklaarde type — als er extra eigenschappen zijn, zal er een compilatiefout optreden.

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

const user: UserProfile = {
  name: "Sam",
  age: 25,
  email: "sam@mail.com" // Fout: extra eigenschap email
};

Om de extra controle te omzeilen, bijvoorbeeld voor objecten met dynamische eigenschappen of gedeeltelijke typisering, worden indexsignaturen of tussenvariabelen gebruikt.

interface FlexibleUser {
  name: string;
  [prop: string]: any; // Indexsignatuur staat nieuwe eigenschappen toe
}

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

Belangrijke kenmerken:

• Extra eigenschapcontroles zijn alleen van toepassing op objectliteraturen die aan expliciet getypeerde variabelen worden toegewezen.
• Controles kunnen worden omzeild met behulp van indexsignaturen of toewijzing via tussenvariabelen.
• Beschermt tegen triviale typfouten en gegevensstructuurfouten.

Vragen met een valstrik.

Als je een object maakt met een extra eigenschap, het toekent aan een variabele zonder type, en vervolgens het type opnieuw toekent, zal Excess Property Checks dan werken?

Nee, de extra controle werkt alleen bij directe toewijzing van literatuur. Als het object van tevoren is gemaakt en daarna alleen het type wordt opgegeven, worden extra eigenschappen niet ontdekt.

const temp = {
  name: "John",
  age: 18,
  foo: "bar"
};
const u: UserProfile = temp; // Geen fout, foo genegeerd

Werken Excess Property Checks voor klassen en class-instanties?

Nee, op klassen en class-instanties wordt deze controle niet uitgevoerd, alleen voor objectliteraturen.

Kan je de extra controles wereldwijd uitschakelen in de TS-instellingen?

Nee, er is geen aparte instelling om deze uit te schakelen. Dit kan echter worden bereikt door voor eigenschappen een indexsignatuur op te geven of de type-affirmatie ('as') te gebruiken om expliciet aan te geven dat controle niet nodig is.

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

Typefouten en anti-patronen

• Het gebruik van type-affirmatie om controle uit te schakelen (kan leiden tot gemiste fouten in de structuur van objecten).
• Ongerechtvaardigd gebruik van indexsignaturen vermindert de striktheid van typebeschrijving.

Praktijkvoorbeeld

Negatief geval

Een ontwikkelaar maakt een interface voor een gebruikersformulier, staat alle eigenschappen toe via [key: string]: any, om te voorkomen dat er fouten optreden bij extra velden.

Voordelen: Er treden geen compilatiefouten op bij dynamische gegevens.

Nadelen: Fouten in de structuur van het formulier of typfouten worden niet gedetecteerd, moeilijk om bugs te vinden.

Positief geval

Een ontwikkelaar specificeert een strikte interface en gebruikt een aparte functie om dynamische gegevens naar een strikte structuur te transformeren, met voorafgaande validatie.

Voordelen: De interface komt altijd overeen met het verwachte contract, de compiler vangt typfouten, hoge onderhoudbaarheid.

Nadelen: Extra code moet worden geschreven voor validatie en mappen van dynamische gegevens