Dans TypeScript, un typage correct de this est crucial pour prendre en charge le schéma de méthode chaining, où les méthodes retournent this pour des appels successifs. Si le type de retour n'est pas spécifié explicitement, TypeScript considère par défaut que l'objet retourné est une instance de la classe actuelle, ce qui est incorrect lors de l'héritage.
Pour résoudre ce problème, on utilise this polymorphe (polymorphic this types) à travers le this retourné :
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 est correctement visible
Le type retourné this garantit que la chaîne de méthodes est correctement typée même pour les héritiers, et pas seulement pour la classe de base.
Peut-on au lieu d'utiliser this dans le type de retour simplement indiquer le nom de la classe (par exemple, retourner Builder) ? Comment cela affectera-t-il les chaînes de méthodes dans les héritiers ?
Réponse :
Si vous retournez Builder au lieu de 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 n'est pas visible !
multiply ne sera pas accessible après setValue, car setValue retournera Builder et non AdvancedBuilder. Seul this dans la signature de la méthode conserve le bon typage dans la chaîne de méthodes.
Histoire
Une API fluent a été créée dans l'équipe de développeurs pour construire une configuration. Les méthodes retournaient le type de la classe de base, pensant que c'était une bonne pratique. Après l'arrivée d'un héritier, tous les méthodes supplémentaires sont devenues invisibles après la chaîne d'appels standard. Conclusion : il a fallu refactoriser l'API en this pour que les clients puissent utiliser les extensions.
Histoire
Dans une bibliothèque interne de décorateurs, un type de classe concret a été retourné explicitement. Les utilisateurs, en utilisant des héritiers, perdaient l'accès aux nouvelles méthodes, recevant "l'objet n'a pas de méthode ...". L'erreur est survenue uniquement lors de l'intégration avec de nouveaux services.
Histoire
Un développeur, en copiant des méthodes d'une ancienne API C#, a réécrit une chaîne de méthodes en TypeScript, retournant le nom de la classe. À l'étape de construction, tout semblait normal, mais dans les héritiers utilisateurs, de nouvelles méthodes étaient perdues. Seule une vérification stricte dans tsconfig a permis d'identifier rapidement ce problème - et de le corriger en utilisant this retourné.