Antwoord.

In TypeScript is de juiste typisering van this cruciaal voor het ondersteunen van het methodeketenpatroon, waarbij methoden this retourneren voor opeenvolgende aanroepen. Als het retourtype niet expliciet is opgegeven, beschouwt TypeScript standaard het geretourneerde object als een instantie van de huidige klasse, wat onjuist is bij overerving.

Om dit probleem op te lossen, wordt polymorfische this (polymorphic this types) gebruikt via het geretourneerde this:

class Builder {
  value: number = 0;
  setValue(v: number): this {
    this.value = v;
    return this;
  }
}

class AdvancedBuilder extends Builder {
  multiply(factor: number): this {
    this.value *= factor;
    return this;
  }
}

const b = new AdvancedBuilder().setValue(5).multiply(2); // multiply is correct zichtbaar

het geretourneerde type this garandeert dat de keten van methoden correct is getypt, zelfs voor afgeleiden klassen, niet alleen voor de basisklasse.

Vraag met een valstrik.

Kan je in plaats van this in het retourtype gewoon de naam van de klasse opgeven (bijvoorbeeld, Builder retourneren)? Hoe zou dat de methodeketens in afgeleiden klassen beïnvloeden?

Antwoord:

Als je Builder retourneert in plaats van this:

class Builder {
  setValue(v: number): Builder {
    //...
    return this;
  }
}

class AdvancedBuilder extends Builder {
  multiply(factor: number): this {
    // ...
    return this;
  }
}

const a = new AdvancedBuilder().setValue(2).multiply(2); // multiply is niet zichtbaar!

multiply zal niet beschikbaar zijn na setValue, omdat setValue Builder retourneert en niet AdvancedBuilder. Alleen this in de methodehandtekening behoudt de juiste typisering in de methodeketen.

Voorbeelden van echte fouten door onbekendheid met de subtiliteiten van het onderwerp

---

Verhaal

In het ontwikkelingsteam werd een fluent API gemaakt voor het bouwen van configuraties. In de methoden werd het type van de basisklasse geretourneerd, wat als een goede praktijk werd beschouwd. Na de komst van een afgeleide klasse werden alle extra methoden onzichtbaar na de keten van standaard aanroepen. Resultaat: de API moest refactoren naar this, zodat klanten gebruik konden maken van de uitbreidingen.

---

Verhaal

In een interne bibliotheek van decorators werd expliciet een specifiek type klasse geretourneerd. Gebruikers verloren bij het gebruik van afgeleiden klassen de toegang tot nieuwe methoden en kregen "object heeft geen methode ...". De fout trad pas op bij integratie met nieuwe services.

---

Verhaal

Een ontwikkelaar, die methoden uit een oude C# API kopieerde, herschreef de methodeketens naar TypeScript, waarbij hij de naam van de klasse retourneerde. Tijdens de build-fase leek alles normaal, maar in gebruikersafgeleiden klassen gingen nieuwe methoden verloren. Alleen een strenge controle in tsconfig hielp om dit probleem snel te identificeren — en het werd gecorrigeerd naar het geretourneerde this.