En bref
Les fonctions TypeScript sont des fonctions JavaScript qui ont signé un contrat : chaque paramètre et chaque retour déclarent leur type, et le compilateur vérifie tous les appels avant l’exécution, transformant en erreurs immédiates les fautes que JavaScript aurait découvertes en production. La mécanique s’apprend vite, annotations sur les paramètres, retour souvent inféré, point d’interrogation des optionnels, et révèle progressivement la puissance du système de types : les unions qui acceptent nombre ou chaîne, les types littéraux qui restreignent aux valeurs permises, les alias qui nomment les formes d’objets attendues, et les types de fonctions eux-mêmes, indispensables pour typer les callbacks omniprésents du JavaScript. Les génériques couronnent l’édifice, la fonction écrite une fois pour tous les types avec le lien préservé entre entrée et sortie. Restent les réglages qui font la vraie sécurité, le mode strict en tête, et la sagesse d’usage : laisser l’inférence travailler, bannir le any réflexe, et typer les frontières avec soin.
TypeScript tient en une promesse : garder tout JavaScript, et attraper avant l’exécution les erreurs qui explosaient chez les utilisateurs. Les fonctions TypeScript sont le cœur de cette promesse, chaque signature devenant un contrat vérifié. Voici le guide pratique complet, des annotations aux génériques, en prolongement de comprendre une fonction, du guide apprendre le TypeScript et du guide complet pour apprendre à coder.
Typer ses fonctions : la mécanique du contrat
Le geste fondateur tient en quelques caractères : function calculerTtc(prixHt: number, taux: number): number { return prixHt * (1 + taux); }, chaque paramètre annoté après deux-points, le type de retour après les parenthèses, et voilà la fonction sous contrat. Le compilateur vérifie désormais chaque appel, refusant la chaîne passée où un nombre est attendu, le paramètre oublié, le retour employé de travers, et cette vérification totale avant exécution, la philosophie des langages compilés portée au monde JavaScript, change concrètement la vie : l’erreur qui aurait produit un NaN silencieux en production devient un soulignement rouge dans l’éditeur, à la seconde où tu la commets. Car c’est le bénéfice le plus tangible au quotidien : l’autocomplétion et la détection instantanée dans l’IDE, nourries par les types, transforment l’écriture même du code, chaque fonction typée documentant ses attentes à tous ses appelants, pour toujours. Toutes les écritures héritées de JavaScript se typent à l’identique, déclarations, expressions et fléchées, const doubler = (n: number): number => n * 2;, TypeScript n’ajoutant que la couche de contrat.
La mécanique se complète de trois raffinements immédiatement utiles. L’inférence d’abord, la politesse du compilateur : le type de retour se déduit du corps, et l’annoter devient souvent facultatif, la pratique courante annotant toujours les paramètres, jamais devinables, et laissant l’inférence gérer le retour, sauf sur les fonctions publiques où l’annotation explicite documente et verrouille. Les optionnels ensuite : le point d’interrogation, function saluer(nom: string, titre?: string), déclare le paramètre facultatif, son type devenant chaîne ou undefined, et le compilateur exigeant qu’on traite ce cas avant usage, la rigueur qui remplace les gardes oubliées ; les valeurs par défaut, héritées de JavaScript, restent la solution élégante quand un repli existe, le type s’inférant de la valeur. Le void enfin pour les fonctions qui ne renvoient rien, et son cousin never pour celles qui ne rendent jamais la main, erreurs levées, boucles infinies, le vocabulaire complet des retours étant posé dès les bases du langage.
La puissance du système : unions, littéraux, types de fonctions
Le système de types révèle sa personnalité avec les unions, la réponse TypeScript à la souplesse JavaScript : function formater(valeur: number | string) accepte nombre ou chaîne, et le compilateur impose alors la discipline qui fait sa réputation, le rétrécissement, vérifier le type effectif, typeof en tête, avant d’user des opérations propres à l’un, la branche nombre accédant aux arrondis, la branche chaîne aux majuscules, chaque condition affinant ce que le compilateur sait de la valeur. Les types littéraux poussent la précision jusqu’aux valeurs elles-mêmes : type Statut = "brouillon" | "publie" | "archive" restreint le paramètre aux trois chaînes permises, la faute de frappe devenant erreur de compilation, l’idiome qui remplace des familles entières de constantes et de vérifications manuelles. Et les alias de types, mariés aux formes d’objets, nomment les structures attendues, type Article = { titre: string; publie: boolean }, la fonction recevant un Article déclarant son besoin en un mot, la documentation vivante à l’échelle du projet, servie par des noms soignés dans l’esprit de bien nommer.
Vient alors le raffinement le plus JavaScript de tous : typer les fonctions elles-mêmes, puisque le langage les passe en valeurs à longueur de code. Le type d’une fonction s’écrit en flèche, (x: number) => number, et il devient indispensable dès qu’un callback entre en scène : function surClic(reaction: (evenement: MouseEvent) => void) déclare exactement ce qu’elle attend, et le compilateur vérifie la compatibilité de chaque fonction confiée, paramètres et retour, l’anarchie des callbacks JavaScript troquée contre des prises électriques normalisées. Les génériques couronnent l’édifice en résolvant l’ultime tension, généralité contre précision : function premier<T>(liste: T[]): T travaille sur tous les types tout en préservant le lien, un tableau de chaînes rendant une chaîne, un tableau de nombres un nombre, là où un type fourre-tout aurait perdu l’information ; c’est le mécanisme qui type toute la bibliothèque standard moderne, les méthodes de tableaux en tête, et le lire précède largement le besoin de l’écrire. À ce stade, la promesse initiale est tenue : la souplesse fonctionnelle du JavaScript, intégralement conservée, intégralement vérifiée.
Strict, any et sagesse d’usage : le TypeScript qui protège vraiment
La sécurité réelle dépend pourtant d’un réglage qu’il faut nommer : le mode strict, l’ensemble d’options du compilateur qui active les vérifications sérieuses, la nullité surveillée en tête, chaque valeur potentiellement absente devant être traitée avant usage, la fin programmée du undefined is not a function qui hante les consoles JavaScript. Tout projet neuf l’active sans débat, et tout tutoriel qui l’omet te prive de l’essentiel. Son ennemi intime s’appelle any, le type qui éteint la vérification : légitime en dépannage aux frontières, données externes pas encore typées, migration progressive d’un code JavaScript, il devient poison en réflexe, chaque any semé rendant aveugle le compilateur sur tout ce qu’il touche ; l’alternative honnête s’appelle unknown, le type qui avoue l’ignorance tout en exigeant la vérification avant usage, la différence entre fermer les yeux et regarder prudemment. La sagesse d’usage complète le tableau : laisser l’inférence travailler plutôt que d’annoter frénétiquement, typer avec soin les frontières du système, entrées d’API, formulaires, bibliothèques, là où le monde extérieur entre, et accepter que le typage soit un investissement, lent au premier jour, rentable dès la première semaine.
Reste à situer l’enjeu professionnel, car il est massif : TypeScript est devenu la langue par défaut du JavaScript sérieux, les frameworks majeurs l’adoptant nativement, React et son écosystème en tête, les offres d’emploi front-end le mentionnant comme une évidence, et sa maîtrise figurant en bonne place des compétences les plus demandées ; typer proprement ses fonctions n’est donc pas un raffinement d’esthète, c’est le geste d’employabilité du développeur web moderne. Le chemin d’apprentissage suit la gradation de ce guide : annotations et optionnels dès le premier jour, unions et alias dès la première semaine, types de fonctions avec les premiers callbacks, génériques en lecture d’abord, en écriture quand le besoin réel se présente, le tout pratiqué sur les exercices TypeScript corrigés puis sur un vrai projet migré, l’exercice révélateur entre tous. Et la boussole finale tient en une phrase : TypeScript ne change pas ce que font tes fonctions, il garantit qu’elles le font, et cette garantie, multipliée par chaque fonction d’un projet et chaque membre d’une équipe, est très exactement ce que les entreprises achètent.
Questions fréquentes
Comment typer une fonction en TypeScript ?
En annotant chaque paramètre après deux-points et, au besoin, le retour après les parenthèses : function calculerTtc(prixHt: number, taux: number): number. La pratique courante annote toujours les paramètres et laisse souvent l’inférence déduire le retour, sauf sur les fonctions publiques.
À quoi sert le point d’interrogation dans les paramètres TypeScript ?
Il déclare le paramètre optionnel : son type devient l’union avec undefined, et le compilateur exige de traiter ce cas avant usage. Quand un repli existe, la valeur par défaut reste la solution élégante, le type s’inférant automatiquement de la valeur fournie.
Pourquoi éviter le type any en TypeScript ?
Parce qu’il éteint la vérification : chaque any rend le compilateur aveugle sur tout ce qu’il touche, ramenant les risques du JavaScript nu. Légitime en dépannage aux frontières, il se remplace en réflexe par unknown, qui avoue l’ignorance tout en exigeant la vérification avant usage.
C’est quoi une fonction générique en TypeScript ?
Une fonction écrite pour tous les types avec le lien préservé entre entrée et sortie : premier(liste: T[]): T rend une chaîne pour un tableau de chaînes, un nombre pour un tableau de nombres. C’est le mécanisme qui type les méthodes de tableaux et toute la bibliothèque moderne.
Sources
Cet article a une vocation informative et pédagogique. Les plateformes, outils et formations éventuellement cités le sont à titre d’exemple ; compare plusieurs options avant de t’engager ou de payer.