ProgrammationDéveloppeur Frontend

Expliquez comment TypeScript réalise une typage strict par rapport à JavaScript. Quelles sont les principales différences, quel avantage cette fonctionnalité apporte-t-elle dans les grands projets ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

TypeScript est une surcouche de JavaScript qui implémente un typage statique (strict). Cela signifie que la vérification des types se produit au moment de la compilation, et non à l'exécution, comme en JavaScript.

Principales différences:

  • Vérification statique des types : les variables, les paramètres de fonction et les valeurs de retour peuvent être explicitement décrits.
  • Types par défaut (inférence de type) : définit implicitement le type d'une variable sur la base de la valeur assignée.
  • Unification de l'API : les IDE et les outils d'analyse de code peuvent afficher les types, compléter automatiquement les champs et prévenir des erreurs.

Avantages dans les grands projets:

  • Norme unique, moins de bugs.
  • Refactoring plus rapide et plus sûr.
  • Le travail d'équipe est simplifié.

Exemple:

type User = { name: string; age: number; } function greet(user: User): string { return 'Hello, ' + user.name; } const u: User = { name: 'Ivan', age: 30 }; greet(u); // Ok

Question piégée.

Question : Peut-on déclarer une variable de type any dans un projet TypeScript, et le projet perdra-t-il ses avantages de typage strict ?

Réponse :

Oui, TypeScript permet d'utiliser le type any, ce qui équivaut à l'absence de typage pour cette variable. Si any est utilisé fréquemment, cela annule le principal avantage de TypeScript — la typologie stricte, et vous courez le risque de rencontrer des erreurs d'exécution typiques, comme en JavaScript.

Exemple:

let data: any = 'test'; data = 42; // Aucune erreur ne surviendra, mais cela peut causer des problèmes

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet.


Histoire

Un développeur a souvent utilisé le type any pour des objets complexes, afin de "progresser plus rapidement". En conséquence, un jour un objet est arrivé avec des champs manquants, et l'application a planté pour des raisons apparemment inexplicables : l'erreur a été mise en production à cause de l'absence de vérification de types.


Histoire

Dans un grand projet, des messages étaient échangés entre deux microservices différents. Un des services a modifié la structure de l'objet, mais TypeScript n'a pas prévenu cela car le type avait été explicitement défini comme any. Le bug a été découvert un mois plus tard suite aux plaintes des utilisateurs.


Histoire

Un jeune développeur n'a pas décrit le type de retour d'une fonction publique, en s'appuyant sur l'inférence automatique de type. Après un refactoring, les attentes de type de l'autre côté ont cessé de fonctionner, entraînant une chaîne de bugs dans tout le projet.