L’inférence en TypeScript est une brique essentielle de ce langage (il gagne ses lettres de noblesse, on ne parle plus de pseudo-langage).
Voici un exemple simple :
Cette inférence est poussée très loin, par exemple :
Néanmoins, il y a des cas qui ne sont pas gérés et cela est un véritable handicap pour le développement.
Nous allons en voir deux en particulier.
Cas 1 d’inférence TypeScript non-gérée : filter
Un exemple valant mieux que 1000 mots, voici une implémentation simple de filter qui provoque une erreur :
TypeScript ne parvient pas à prédire le type issus de filter, pour palier on est obligé de contourner le problème, ou de tricher pour le résoudre :
Dans tous les cas, cela donne au code beaucoup moins de visibilité, surtout qu’il est difficile d’admettre que ce cas là ne soit pas géré.
Il y a néanmoins une bonne nouvelle. La version 5.5 de TypeScript gère l’inférence de .filter.
L’inférence TypeScript en try … catch
Il s’agit d’un point noir de TypeScript, l’absence d’inférence dans les clauses catch.
Voici un exemple :
Cela crée énormément de problème, il est impossible de typer le paramètre error dans le catch et donc de pouvoir l'utiliser correctement par la suite.
Pour éviter cela, les puristes vont vouloir supprimer la notion même de try … catch.
Cette fonction retourne soit un string, soit une erreur typée. Elle peut donc être traitée plus en avant dans le code.
L’utilisation de librairie, telle que LIEN effect permettent, via le pattern fonctionnel, de pouvoir traiter le problème de typage des erreurs :
Ici, on constate que le catch est wrappé dans un effect (un programme) et est fortement typé.
Pour l’instant, la mise à jour de la prise en charge du typage en TypeScript est uniquement dans une phase de proposition.
La programmation fonctionnelle, bien que très élégante, fait peur aux développeurs. Car elle oblige à revoir l'ensemble des paradigmes du développement.
J'espère que cet article vous aura apporté un peu plus de connaissance aujourd’hui.
