Typage des callbacks en TypeScript : comment définir un type pour une fonction de gestion

Comment arrêter d'utiliser any pour les callbacks et commencer à vivre : guide complet pour typer les fonctions de gestion en TypeScript

Avez-vous déjà écrit quelque chose comme callback: any dans les paramètres d'une méthode ? Si oui — bienvenue au club. Si non — vous êtes soit un génie, soit vous débutez tout juste votre parcours en TypeScript. C'est une blague. Mais chaque blague contient une part de vérité : selon les données de Stack Overflow, la question "How to define type for a function callback (as any function type, not universal any)" recueille des milliers de vues. Et ce n'est pas un hasard.

Le problème est que any est comme un trou noir : il aspire toute la sécurité de typage de votre code. Vous perdez l'autocomplétion, la vérification des arguments et la possibilité de détecter des bugs à la compilation. Mais le plus frustrant — any comme type de callback tue l'idée même de TypeScript. Voyons comment typer correctement une fonction callback dans un paramètre de méthode, pour que le code soit à la fois sûr et élégant.

Pourquoi Function n'est pas mieux que any ?

Le premier réflexe d'un débutant est d'utiliser le type intégré Function. Après tout, c'est le type "n'importe quelle fonction", donc ça devrait convenir. Mais non. Function est un type aussi "poubelle" que any. Il ne donne aucune information sur la signature : combien de paramètres la fonction accepte, ce qu'elle retourne, quels sont les types des arguments. Vous dites simplement au compilateur : "Fais-moi confiance, je sais ce que je fais". Spoiler : généralement, vous ne le savez pas.

// Mauvais : aucune vérification de type\nfunction processData(callback: Function) {\n    callback(42, "hello"); // Erreur ? Qui sait\n}

Avec cette approche, vous perdez tous les avantages du typage statique. Corrigeons cela.

Étape 1. Typage de base d'un callback : simple et clair

La manière la plus simple et correcte est de déclarer le type de la fonction directement dans le paramètre. Pour cela, on utilise la syntaxe fléchée (paramètres) => type_de_retour. C'est ce qu'on appelle un function type en TypeScript.

// Bien : on définit explicitement la signature\nfunction fetchData(url: string, onSuccess: (data: string) => void): void {\n    // ... une certaine logique\n    const result = "Données du serveur";\n    onSuccess(result);\n}\n\n// Utilisation — avec autocomplétion et vérification\nfetchData("/api/users", (data) => {\n    console.log(data.toUpperCase()); // data — string, tout va bien\n});

Notez le void dans le type de retour. Cela signifie que nous n'attendons pas de valeur spécifique du callback. Si le callback retourne quelque chose, cela sera ignoré. Si vous attendez un résultat, utilisez un type concret.

Étape 2. Callback avec plusieurs paramètres

Les callbacks acceptent souvent plus d'un argument. Par exemple, un gestionnaire d'erreurs ou un événement avec des données. C'est tout aussi simple — on liste tous les paramètres séparés par des virgules.

// Type pour un callback avec erreur et résultat\nfunction loadUser(\n    userId: number,\n    callback: (error: Error | null, user: { name: string; age: number } | null) => void\n): void {\n    // ... logique de chargement\n    const user = { name: "Anna", age: 30 };\n    callback(null, user);\n}\n\n// Utilisation\nloadUser(42, (err, user) => {\n    if (err) {\n        console.error("Erreur :", err.message);\n        return;\n    }\n    if (user) {\n        console.log(`Bonjour, ${user.name} !`);\n    }\n});

Vous voyez comment TypeScript suggère automatiquement les types de err et user ? C'est cela, le typage d'une fonction callback en action. Sans any, sans magie — seulement une vérification stricte.

Étape 3. Créer des types réutilisables pour les callbacks

Si le même type de callback est utilisé à plusieurs endroits, il n'est pas nécessaire de le dupliquer à chaque fois. Extrayez-le dans un type alias ou une interface séparé. Cela améliore la lisibilité et simplifie la maintenance.

// Déclaration