TypeScript

Pourquoi TypeScript ?

Comprendre le problème que ça résout, avant d'apprendre la syntaxe.

1. Regarde ce qui plante en JavaScript pur

   // JavaScript classique — ce code est accepté sans broncher
   function calculerPrix(prix, quantite) {
     return prix * quantite;
   }
   
   calculerPrix("dix", 3);  // "dix" * 3 → NaN, et personne n'est prévenu

   En JavaScript, rien ne t'empêche d'appeler calculerPrix avec une chaîne de caractères à la place d'un nombre. L'erreur (NaN, « Not a Number ») n'apparaît que quand le code tourne — parfois chez un vrai utilisateur, des heures après que tu as écrit la fonction.
2. Le même code, en TypeScript

   // TypeScript — les ": type" sont les annotations
   function calculerPrix(prix: number, quantite: number) {
     return prix * quantite;
   }
   
   calculerPrix("dix", 3);  // erreur IMMÉDIATE, avant même d'exécuter le code

   Le : number après chaque paramètre dit à TypeScript « ceci doit toujours être un nombre ». Si tu te trompes, ton éditeur (VS Code, etc.) souligne la ligne en rouge tout de suite — tu corriges avant même d'enregistrer, pas après un bug en production.
   👁 Essaie toi-même : colle les deux blocs sur le Playground. Le premier (JS) ne montre aucune erreur. Le second souligne "dix" en rouge avec le message Argument of type 'string' is not assignable to parameter of type 'number'.
3. Retiens l'idée en une phrase
   TypeScript n'exécute jamais de code différemment de JavaScript — il se contente de vérifier les types avant l'exécution et de refuser de compiler si tu t'es trompé. C'est un correcteur orthographique pour ton code, pas un nouveau langage à part entière.

Types de base

Les quatre types que tu utiliseras dans 90% de ton code.

Prérequis : étape 1 lue.

1. Texte, nombre, booléen

   let nom: string = "Samba";
   let age: number = 32;
   let estConnecte: boolean = true;

   La syntaxe est toujours la même : nom-de-variable: type = valeur. Trois types couvrent la grande majorité des cas : string (texte, entre guillemets), number (tout nombre, entier ou décimal — pas de type séparé pour les décimaux), boolean (seulement true ou false).
   👁 Essaie toi-même : écris age = "trente-deux"; juste en dessous. TypeScript souligne la ligne : Type 'string' is not assignable to type 'number'.
2. Un tableau

   let notes: number[] = [12, 15, 8, 17];
   let prenoms: string[] = ["Awa", "Moussa", "Fatou"];

   type[] veut dire « un tableau qui ne contient que ce type ». notes.push("bien") serait refusé — un tableau de number[] ne peut accueillir que des nombres.
3. Laisse TypeScript deviner tout seul, quand c'est évident

   let ville = "Paris";  // pas besoin d'écrire ": string", TypeScript le devine
   ville = 75;            // erreur quand même — le type est "verrouillé" dès l'affectation

   C'est l'inférence de type : si tu donnes une valeur dès la déclaration, TypeScript comprend le type tout seul. Tu n'as besoin d'écrire : string explicitement que quand la valeur n'est pas encore connue (ex. un paramètre de fonction, vu au chapitre suivant).
   👁 Essaie toi-même : survole ville avec ta souris dans VS Code (ou le Playground) — une infobulle affiche let ville: string, même si tu ne l'as jamais écrit.
4. Le piège à éviter : any

   let donnee: any = "texte";
   donnee = 42;        // accepté
   donnee = true;      // accepté aussi — plus aucune vérification

   any dit à TypeScript « n'importe quel type, arrête de vérifier ». Ça compile toujours, mais tu perds tout l'intérêt de TypeScript. Évite any — si tu ne connais pas encore le type exact, préfère unknown (même idée, mais TypeScript t'oblige à vérifier le type avant de t'en servir).

Typer une fonction

Sécuriser ce qui entre (les paramètres) et ce qui sort (la valeur retournée) d'une fonction.

Prérequis : étape 2 validée.

1. Type des paramètres et du retour

   function additionner(a: number, b: number): number {
     return a + b;
   }

   Chaque paramètre est typé individuellement (a: number, b: number). Le : number juste avant l'accolade { type ce que la fonction return. Si le corps de la fonction retourne autre chose qu'un number, TypeScript refuse.
   👁 Essaie toi-même : remplace return a + b; par return "résultat: " + (a + b); — TypeScript souligne cette ligne, car une chaîne ne correspond pas au : number promis.
2. Une fonction qui ne retourne rien

   function afficherMessage(texte: string): void {
     console.log(texte);
   }

   void veut dire « cette fonction ne retourne aucune valeur exploitable » — utilisé pour les fonctions qui font une action (afficher, envoyer un email...) sans return.
3. Fonction fléchée (la forme la plus courante en React)

   const multiplier = (a: number, b: number): number => a * b;

   Même principe, écriture différente — c'est la syntaxe que tu croiseras le plus dans les composants React de tes guides (ex. const handleClick = () => { ... }).
   👁 Essaie toi-même : appelle multiplier(4, "deux") — l'erreur pointe directement le deuxième argument, avant même que la fonction s'exécute.

Objets & interfaces

Décrire la forme exacte d'un objet — la brique la plus utilisée dans un vrai projet (un utilisateur, un produit, une commande...).

Prérequis : étape 3 validée.

1. Type inline sur un objet

   let utilisateur: { nom: string; age: number } = {
     nom: "Aziz",
     age: 32,
   };

   Fonctionne, mais devient illisible dès que l'objet grossit ou que tu dois le réutiliser ailleurs (dans une autre fonction, un autre fichier). D'où l'interface ci-dessous.
2. La même chose avec une interface — la façon propre de faire

   interface Utilisateur {
     nom: string;
     age: number;
   }
   
   const utilisateur: Utilisateur = {
     nom: "Aziz",
     age: 32,
   };

   Une interface nomme une forme d'objet une seule fois, réutilisable partout (function afficher(u: Utilisateur) { ... }). C'est l'équivalent TypeScript d'un modèle Prisma ou d'un schéma de base de données, mais côté code.
   👁 Essaie toi-même : retire age: 32, de l'objet — TypeScript refuse avec Property 'age' is missing. Ajoute une propriété ville: "Paris" non prévue par l'interface — refusé aussi (Object literal may only specify known properties).
3. Réutilise l'interface dans une fonction

   function saluer(u: Utilisateur): string {
     return `Bonjour ${u.nom}, tu as ${u.age} ans.`;
   }

   C'est exactement ce que tu écriras pour typer les props d'un composant React (étape 8) ou le retour d'une requête Prisma (prisma.utilisateur.findMany() renvoie un tableau de ce type).

Union & types littéraux

Limiter une valeur à un ensemble précis de possibilités — très utilisé pour un statut, un rôle, une catégorie.

Prérequis : étape 4 validée.

1. Une variable qui accepte plusieurs types

   let identifiant: string | number;
   identifiant = "abc123";  // accepté
   identifiant = 42;        // accepté aussi
   identifiant = true;      // refusé

   Le | (« ou ») crée une union : la variable peut être l'un OU l'autre des types listés, jamais un troisième.
2. Le cas le plus utile : limiter à des valeurs exactes (types littéraux)

   let statut: "en_attente" | "payee" | "annulee";
   statut = "payee";     // accepté
   statut = "en cours";  // refusé — cette chaîne exacte n'est pas dans la liste

   Au lieu d'un string générique (qui accepterait n'importe quelle faute de frappe comme "payé" ou "Payee"), tu listes précisément les seules valeurs valides. C'est exactement ce que fait un enum Prisma dans schema.prisma, côté TypeScript.
   👁 Essaie toi-même : écris statut = "Payee"; (majuscule) — refusé, car ce n'est pas exactement une des trois chaînes autorisées.
3. Combiné dans une interface

   interface Commande {
     id: string;
     statut: "en_attente" | "payee" | "annulee";
   }

   C'est la même logique que la Server Action createProduit ou createQueue de tes autres guides — le champ statut ne peut jamais contenir une valeur inattendue, ni dans le code, ni via une faute de frappe.

Optionnel, null & undefined

Gérer proprement les valeurs qui peuvent manquer — la source n°1 de bugs en JavaScript (« Cannot read property of undefined »).

Prérequis : étape 5 validée.

1. Une propriété facultative

   interface Produit {
     nom: string;
     description?: string;  // le "?" veut dire : peut être absente
   }
   
   const p1: Produit = { nom: "Chaise" };                              // accepté, pas de description
   const p2: Produit = { nom: "Table", description: "En bois massif" }; // accepté aussi

   Sans le ?, TypeScript exigerait description sur chaque objet. Avec, c'est facultatif — mais TypeScript te force alors à vérifier qu'elle existe avant de l'utiliser (étape suivante).
2. Vérifier avant d'utiliser une valeur optionnelle

   function afficherDescription(p: Produit) {
     console.log(p.description.toUpperCase());  // erreur : peut être undefined
   }
   
   function afficherDescriptionCorrige(p: Produit) {
     if (p.description) {
       console.log(p.description.toUpperCase());  // accepté : TS sait qu'elle existe ici
     }
   }

   TypeScript refuse d'appeler une méthode (.toUpperCase()) sur une valeur qui pourrait être undefined — c'est exactement le bug JavaScript classique Cannot read properties of undefined, mais détecté avant l'exécution plutôt que chez l'utilisateur.
   👁 Essaie toi-même : colle la première fonction (sans le if) — TypeScript souligne p.description avec 'p.description' is possibly 'undefined'.
3. Le raccourci ?. (optional chaining)

   console.log(p.description?.toUpperCase());  // si "description" n'existe pas, retourne undefined au lieu de planter

   Équivalent plus court du if précédent, très courant dans le code React de tes guides (ex. session?.user.id pour l'authentification, déjà vu dans les guides backoffice/e-commerce/SaaS).

Generics — les bases

Écrire une fonction qui marche avec n'importe quel type, sans perdre la sécurité des types. La notion la plus abstraite du cours — vas-y doucement.

Prérequis : étape 6 validée.

1. Le problème que les generics résolvent

   function premierElement(tableau: any[]) {
     return tableau[0];
   }
   
   const x = premierElement([1, 2, 3]);        // x est "any" — TS a perdu la trace du type
   const y = premierElement(["a", "b", "c"]);  // y est "any" aussi, alors que c'est forcément une string

   Avec any[], la fonction accepte tout, mais TypeScript ne peut plus te dire ce que x ou y contiennent réellement — tu as perdu toute la sécurité de typage à l'intérieur de la fonction.
2. La même fonction, avec un generic <T>

   function premierElement<T>(tableau: T[]): T {
     return tableau[0];
   }
   
   const x = premierElement([1, 2, 3]);        // x est bien typé "number"
   const y = premierElement(["a", "b", "c"]);  // y est bien typé "string"

   T est un « type variable » : un espace réservé que TypeScript remplace automatiquement par le vrai type à chaque appel — number pour le premier appel, string pour le second. Tu peux l'appeler T (convention) ou n'importe quel nom, comme un paramètre normal mais pour un type.
   👁 Essaie toi-même : survole x puis y dans VS Code/Playground — les infobulles affichent const x: number et const y: string, TypeScript a deviné tout seul.
3. Là où tu en verras le plus souvent : useState en React

   const [age, setAge] = useState<number>(0);
   // setAge("trente") serait refusé : age doit toujours rester un "number"

   Tu n'as pas besoin d'écrire tes propres generics au quotidien — mais tu vas constamment en utiliser (useState<T>, Array<T>, les hooks de tes composants React) donc reconnaître la syntaxe <...> et savoir qu'elle « fixe » un type suffit largement pour l'instant.

TypeScript avec React

Tout assembler sur un composant réel, comme ceux que tu écris dans les guides vitrine/backoffice/e-commerce/SaaS/mobile.

Prérequis : étapes 1 à 7 validées.

1. Typer les props d'un composant

   // components/carte-produit.tsx
   interface CarteProduitProps {
     nom: string;
     prix: number;
     enPromo?: boolean;  // optionnel, vu à l'étape 6
   }
   
   export default function CarteProduit({ nom, prix, enPromo }: CarteProduitProps) {
     return (
       <div>
         <h3>{nom}</h3>
         <p>{prix} €{enPromo ? " — en promo" : ""}</p>
       </div>
     );
   }

   C'est l'interface de l'étape 4, appliquée aux props d'un composant. Si quelqu'un (toi, dans trois mois) utilise <CarteProduit nom="Chaise" /> sans prix, TypeScript refuse — impossible d'oublier une prop obligatoire, contrairement au JavaScript classique.
   👁 Essaie toi-même : dans un fichier qui importe ce composant, écris <CarteProduit nom="Chaise" prix="20" /> (avec des guillemets autour de 20) — erreur immédiate, prix attend un number, pas une string.
2. Typer un état avec useState

   "use client";
   import { useState } from "react";
   
   export default function Compteur() {
     const [total, setTotal] = useState<number>(0);
   
     return (
       <button onClick={() => setTotal(total + 1)}>
         Cliqué {total} fois
       </button>
     );
   }

   Le generic (étape 7) sur useState<number> garantit que total reste un nombre pendant toute la vie du composant — setTotal("beaucoup") serait refusé.
3. Typer les données qui viennent de la base (Prisma)

   import { prisma } from "@/lib/db/client";
   
   export default async function ListeProduits() {
     const produits = await prisma.produit.findMany();
     // "produits" est déjà typé automatiquement par Prisma — pas d'interface à écrire à la main
   
     return (
       <ul>
         {produits.map((produit) => (
           <li key={produit.id}>{produit.nom}</li>
         ))}
       </ul>
     );
   }

   Bonne nouvelle pour la suite : Prisma génère lui-même les types TypeScript à partir de ton schema.prisma (vu dans les guides backoffice/e-commerce/SaaS). Tu n'as pas besoin de réécrire une interface pour chaque modèle — produit.nom est déjà typé string, produit.prix déjà typé number, automatiquement.