ProgrammationDéveloppeur Fullstack

Comment implémenter et typiser correctement une fonction de rappel (callback) avec des paramètres qui peuvent être optionnels ou avoir des valeurs par défaut ? Quelles difficultés peuvent survenir et comment les éviter ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Historique de la question :

Les fonctions de rappel sont une pratique courante en JS et TS pour la programmation asynchrone et la délégation de responsabilité. En TypeScript, la typisation de telles fonctions est une partie importante de la sécurité, surtout si les paramètres peuvent être optionnels ou avoir des valeurs par défaut.

Problème :

Dans le JS dynamique, l'absence de typisation des arguments de callback peut mener à des erreurs de transmission de valeur, à des confusions avec undefined et à un mauvais ordre des paramètres. En TypeScript, la typisation est nécessaire pour éviter de tels problèmes, mais il est difficile de respecter tous les nuances liés à l'optionnalité, à l'ordre et aux valeurs par défaut.

Solution :

Indiquer explicitement les types de tous les paramètres, désigner les paramètres optionnels avec un point d'interrogation et spécifier les valeurs par défaut directement lors de la déclaration de la fonction, tout en veillant à les décrire correctement dans le type.

Exemple de code :

function fetchData( url: string, callback: (data: any, error?: Error) => void ) { // ... } // Callback avec un paramètre optionnel error fetchData('/api', (data, error) => { if (error) { // traitement } else { // succès } }); // Callback avec un paramètre par défaut function process( cb: (x: number, y?: number) => void = (x, y = 10) => { /* ... */ } ) { /* ... */ }

Caractéristiques clés :

  • Pour les paramètres optionnels, on utilise le signe "?".
  • Pour les valeurs par défaut, on spécifie la valeur par défaut dans la définition de la fonction.
  • La typisation facilite la maintenance du code et réduit le nombre d'erreurs.

Questions pièges.

Le consommateur du callback doit-il tenir compte explicitement de tous les paramètres, y compris les optionnels ?

Non, il peut omettre les paramètres optionnels, et TypeScript ne renverra pas d'erreur — le traitement s'effectue correctement grâce à la syntaxe du point d'interrogation.

Peut-on rendre le premier paramètre du callback optionnel et le second obligatoire ?

Non. Les paramètres optionnels doivent toujours être à la fin de la liste des arguments. Enfreindre l'ordre entraînera une erreur de typisation.

Que se passe-t-il si on ne spécifie pas l'optionnalité d'un paramètre mais qu'on ne le passe pas lors de l'appel ?

TypeScript renverra une erreur — si le paramètre est obligatoire, il doit être fourni. Seuls les paramètres optionnels ou avec des valeurs par défaut peuvent être omis.

Erreurs typiques et anti-paternités

  • Enfreindre l'ordre des paramètres optionnels et obligatoires (d'abord les obligatoires, puis les optionnels).
  • Absence de spécification explicite des types ou "any" — entraîne une perte des avantages de TypeScript.
  • Essayer de passer undefined à la place d'une valeur et s'attendre à ce que la valeur par défaut soit utilisée (elle ne s'applique que si l'argument est absent).

Exemple de la vie quotidienne

Cas négatif

On a marqué le deuxième argument du callback comme obligatoire, mais on ne l'a pas fourni lors de l'appel. On a obtenu une erreur de compilation.

Avantages :

  • Code rapidement et simplement écrit sans précisions.

Inconvénients :

  • Ne compile pas.
  • Perte de flexibilité et responsabilité confuse.

Cas positif

On a typé le callback avec un paramètre optionnel :

(cb: (x: number, y?: number) => void)

ou on a défini une valeur par défaut :

f = (x: number, y = 10) => { ... }

Avantages :

  • Garantie de l'absence d'erreurs lors de l'appel des callbacks.
  • Lisibilité et maintenabilité.

Inconvénients :

  • Nécessité d'être attentif à l'ordre des paramètres.