TypeScript : Pourquoi et comment

Tu sais écrire du JavaScript. Tu as peut-être remarqué sa plus grande force... qui est aussi sa plus grande faiblesse : il est dynamiquement typé. Une variable peut contenir n'importe quoi, une fonction accepter n'importe quel argument. Souple, mais dangereux. TypeScript est né pour reprendre le contrôle.

# Le problème que JavaScript pose

En JavaScript, rien ne vérifie les types avant l'exécution. Le code suivant est parfaitement valide pour le moteur :

function prix(quantite, prixUnitaire) {
  return quantite * prixUnitaire;
}

prix(3, 10);      // 30   ✓
prix(3, "10");    // 30   ... par chance (JS convertit "10" en nombre)
prix("3€", 10);   // NaN  ← bug silencieux, aucun avertissement

function prix(quantite, prixUnitaire) {

  return quantite * prixUnitaire;

}

prix(3, 10);      // 30   ✓

prix(3, "10");    // 30   ... par chance (JS convertit "10" en nombre)

prix("3€", 10);   // NaN  ← bug silencieux, aucun avertissement

Le dernier appel est un bug. Mais JavaScript ne dit rien : pas d'erreur, pas d'alerte. Le NaN se propage, et tu ne le découvres qu'à l'exécution - souvent en production, souvent trop tard. Sur un gros projet, ce genre d'erreur devient un puits à bugs.

# TypeScript, c'est quoi ?

TypeScript (TS) est un sur-ensemble de JavaScript créé par Microsoft en 2012. « Sur-ensemble » veut dire une chose précise : tout code JavaScript valide est déjà du TypeScript valide. TS ne remplace pas JS, il l'enrichit d'une seule grande chose : un système de types statique, vérifié avant l'exécution.

Deux idées à retenir :

• Les types sont vérifiés à la compilation, pas à l'exécution. TS attrape les erreurs pendant que tu écris, dans l'éditeur.
• Le navigateur ne comprend pas TypeScript. Le code TS est transpilé (traduit) en JavaScript ordinaire avant de tourner. À l'arrivée, ce qui s'exécute, c'est du JS - les types ont disparu.

# Les bases du typage

On annote les valeurs avec : type. Le même exemple qu'au début, mais en TS :

function prix(quantite: number, prixUnitaire: number): number {
  return quantite * prixUnitaire;
}

prix("3€", 10);
// ❌ Erreur dès l'écriture, avant même de lancer le code :
//    Argument of type 'string' is not assignable to parameter of type 'number'.

function prix(quantite: number, prixUnitaire: number): number {

  return quantite * prixUnitaire;

}

prix("3€", 10);

// ❌ Erreur dès l'écriture, avant même de lancer le code :

//    Argument of type 'string' is not assignable to parameter of type 'number'.

Le bug est signalé avant l'exécution. C'est tout l'intérêt.

Quelques types courants :

let nom: string = "Baptiste";
let age: number = 25;
let actif: boolean = true;

// Inférence : TS devine souvent le type, inutile de l'écrire
let ville = "Toulouse"; // TS sait déjà que ville est un string

// Décrire la forme d'un objet avec une interface
interface Utilisateur {
  nom: string;
  age: number;
  email?: string; // le ? rend le champ optionnel
}

function saluer(u: Utilisateur): string {
  return `Bonjour ${u.nom}`;
}

// Type union : plusieurs types possibles
let identifiant: string | number;

let nom: string = "Baptiste";

let age: number = 25;

let actif: boolean = true;

// Inférence : TS devine souvent le type, inutile de l'écrire

let ville = "Toulouse"; // TS sait déjà que ville est un string

// Décrire la forme d'un objet avec une interface

interface Utilisateur {

  nom: string;

  age: number;

  email?: string; // le ? rend le champ optionnel

}

function saluer(u: Utilisateur): string {

  return `Bonjour ${u.nom}`;

}

// Type union : plusieurs types possibles

let identifiant: string | number;

# JavaScript vs TypeScript

TS ne rend pas ton code plus rapide et n'ajoute aucune fonctionnalité à l'exécution. Il rend ton code plus sûr et plus lisible pendant que tu l'écris. Sur un petit script, JS suffit ; sur une vraie application, TS devient vite indispensable.

# Et le TSX dans tout ça ?

Souviens-toi : en React, un composant retourne du JSX (du balisage dans du JavaScript), et un fichier qui en contient prend l'extension .jsx.

Avec TypeScript, c'est exactement pareil, en typé : JSX + TypeScript = TSX, dans des fichiers .tsx. L'intérêt saute aux yeux sur les props d'un composant. En React « nu », rien ne garantit qu'on passe les bonnes props :

interface Props {
  nom: string;
  age?: number;
}

function Salutation({ nom, age }: Props) {
  return <h1>Bonjour {nom} !</h1>;
}

// <Salutation nom="Baptiste" />   ✓
// <Salutation age={25} />         ❌ prop 'nom' manquante - erreur avant l'exécution

interface Props {

  nom: string;

  age?: number;

}

function Salutation({ nom, age }: Props) {

  return <h1>Bonjour {nom} !</h1>;

}

// <Salutation nom="Baptiste" />   ✓

// <Salutation age={25} />         ❌ prop 'nom' manquante - erreur avant l'exécution

Le composant documente lui-même ce qu'il attend, et l'éditeur te prévient si tu te trompes. C'est précisément ce qui manquait dans notre note sur les composants, où les props n'étaient pas typées.

# À retenir

• TypeScript = JavaScript + un système de types vérifié avant l'exécution. Tout JS valide est du TS valide.
• Il attrape à l'écriture des bugs que JS ne révélerait qu'à l'exécution.
• Les types sont transpilés puis effacés : le navigateur n'exécute que du JavaScript, sans aucun type.
• TSX = JSX typé : des composants React dont les props sont vérifiées, ce qui les rend plus sûrs et auto-documentés.

Pour la suite : ces types prennent tout leur sens en construisant des interfaces. Direction React & Next.js : Introduction.