11 conseils pour devenir un meilleur programmeur TypeScript [Traduction]

 (velog.io)
26 points par xguru 2023-01-04 | 6 commentaires | Partager sur WhatsApp

#1 Penser en termes d’{ensembles (Set)}
#2 Comprendre les types déclarés et les types restreints (narrowed)
#3 Utiliser des unions discriminées plutôt que des champs optionnels
#4 Utiliser des prédicats de type pour éviter les assertions de type
#5 Contrôler la distribution des types union
#6 Vérifier les cas non traités à la compilation grâce à des vérifications exhaustives
#7 Utiliser type plutôt que interface
#8 Utiliser des tuples plutôt que des tableaux lorsque c’est pertinent
#9 Contrôler si le type inféré doit être générique ou spécifique
#10 Utiliser infer pour créer des paramètres de type génériques supplémentaires
#11 Faire preuve de créativité dans la manipulation des types pour rester DRY
Conclusion

À lire aussi

6 commentaires

 
tested 2023-01-04

Le point 7 semble avoir été écrit du point de vue de React.
Pour ma part, je préfère Interface à Type. C’est aussi une syntaxe présente dans d’autres langages.
 
alstjr7375 2023-01-04

Moi aussi. Il me semble qu’autrefois, le handbook TypeScript recommandait aussi de privilégier autant que possible les interfaces.
 
bichi 2023-01-04

Tout est bien, mais le point 7, « utiliser type plutôt qu'interface », franchement ? On ne peut pas vraiment appeler ça un conseil. Il y a des cas où interface est plus expressif, par exemple : interface Foo {(b: number): A; (): B}
 
a741593 2023-01-04

Je ne cherche pas à défendre type, mais je ne comprends pas bien en quoi l’exemple avec une meilleure expressivité est plus parlant. L’exemple en question ne peut-il pas aussi être exprimé de la même façon avec type ?

interface Foo {(b: number): A; (): B}
type Foo = {(b: number): A; (): B}
 
harimkims 2023-01-05

J’ai trouvé dans le livre Effective TypeScript un passage qui résume quand utiliser un type ou une interface, alors je le cite ici.

Tirons une conclusion sur le choix entre type et interface. S’il s’agit d’un type complexe, il ne faut pas hésiter : utilisez un alias de type. En revanche, pour un type d’objet simple qui peut être exprimé aussi bien avec un type qu’avec une interface, il faut raisonner en termes de cohérence et d’extension. Si vous travaillez dans une base de code qui utilise systématiquement des interfaces, utilisez des interfaces ; si elle utilise systématiquement des types, utilisez des types.

Si vous êtes sur un projet dont le style n’est pas encore établi, il faut réfléchir à la possibilité d’une extension future. Si vous devez écrire une déclaration de type pour une API, il vaut mieux utiliser une interface. C’est utile, car lorsque l’API évolue, les utilisateurs peuvent fusionner de nouveaux champs via l’interface. En revanche, si une fusion de déclarations se produit sur des types utilisés uniquement en interne dans le projet, c’est le signe d’une mauvaise conception. Dans ce cas, il faut donc utiliser un type.