Antwoord.

Achtergrond: In JavaScript maken functies vaak gebruik van destructurering van objecten direct in de handtekening. In TypeScript vereist deze aanpak een duidelijke beschrijving van de structuur van de te destructureren parameters en het instellen van standaardwaarden - anders kunnen er fouten optreden bij het verwijzen naar niet-bestaande eigenschappen en foutieve type-inferentie.

Probleem: Het is niet altijd duidelijk hoe de type van de gehele parameter of de afzonderlijke geneste eigenschappen in het te destructureren object correct te beschrijven, vooral bij optionele en geneste velden, evenals waarden met standaardinstellingen.

Oplossing: Beschrijf altijd een apart type of interface voor de structuur van de functieparameters, geef duidelijk aan welke velden verplicht, welke optioneel zijn, en stel standaardwaarden in de functie zelf of rechtstreeks in de parameters in met behulp van ES6-syntaxis.

Voorbeeldcode:

interface UserOptions {
  name: string;
  age?: number;
  address?: { city: string; zipcode?: string };
}

function registerUser(
  { name, age = 18, address = { city: 'Onbekend' } }: UserOptions
): string {
  return `${name}, ${age}, ${address.city}`;
}

Belangrijke kenmerken:

Voor het destructureren van geneste parameters gebruik altijd een interface of type.
Stel standaardwaarden voor velden in de functiehandtekening in.
Denk altijd na over scenario's waarin optionele eigenschappen (age?, address?) kunnen ontbreken.

Vragen met een twist.

Mag je de typeomschrijving van het objectparameter overslaan - vertrouwend op automatische inferentie?

Nee, dat is gevaarlijk. Als je het type UserOptions niet opgeeft, zal de compiler geen waarschuwingen geven over verplichte eigenschappen, standaardwaarden worden niet opgepakt voor geneste velden, en er zullen impliciete fouten optreden bij het gebruik.

function example({ x, y }) { ... } // x en y zijn any

Hoe stel je een standaardwaarde in voor een genest object door gedeeltelijk eigenschappen te vervangen?

Gebruik spread. Echter, spread “voegt” geen types samen, als het type address optioneel is. Je moet een controle uitvoeren of expliciet een standaardwaarde opgeven.

function fn({ obj = { foo: 1 } }: { obj?: { foo: number } }) {
  const address = { foo: 42, ...obj };
}

Wat is het gevaar van destructurering met optionele velden zonder standaardwaarde?

Als je de standaardwaarde voor optionele eigenschappen weglaat, kunnen verwijzingen naar eigenschappen (bijvoorbeeld address.city) leiden tot runtime-fouten. Het is beter om expliciet ? en een standaardwaarde op te geven.

function danger({ address }: { address?: { city: string } }) {
  console.log(address.city); // Fout, address kan undefined zijn
}

Veelvoorkomende fouten en anti-patronen

Impliciete typisering van destructurerende argumenten (any)
Ontbreken van een standaardwaarde voor geneste/optionele eigenschappen
Geen gebruik van interfaces en type aliasen voor structurele parameters

Voorbeeld uit het leven

Negatieve case

In oude code werd het parametersobject gedestructureerd zonder duidelijke typisering. Toen er een nieuw veld aan de functie werd toegevoegd, werden niet alle gebruiksplekken automatisch gevonden, wat leidde tot breuken in productie-oproepen.

Voordelen:

Snel en eenvoudig te schrijven

Nadelen:

Geen veiligheid en controle over de structuur
Kwetsbaarheid bij wijzigingen

Positieve case

Interfaces werden geïntroduceerd voor al dergelijke functies, tests werden uitgevoerd voor scenario's met undefined en standaardwaarden, en de compiler hints maakten het eenvoudig om grootschalige wijzigingen aan te brengen.