TypeScript avec React : décryptage et bonnes pratiques

Depuis que j’ai commencé à utiliser TypeScript dans mes projets React en 2019, je ne suis jamais revenu en arrière. Après plus de 12 ans de développement web, je peux affirmer que cette combinaison est devenue un standard de l’industrie. Pourtant, beaucoup de développeurs hésitent encore à franchir le pas, intimidés par la courbe d’apprentissage ou persuadés que le typage statique ralentit leur productivité. Dans ce guide, je vous partage mon expérience concrète, mes erreurs passées et les bonnes pratiques que j’applique au quotidien pour tirer le meilleur de reactjs typescript.

Pourquoi utiliser TypeScript avec React

Quand on travaille sur un projet React en JavaScript pur, tout fonctionne bien au début. Les composants sont petits, l’équipe connaît le code par cœur, les bugs sont rares. Mais dès que le projet grossit, les problèmes apparaissent : une prop mal nommée, un objet dont la structure a changé sans prévenir, un state qui contient undefined alors qu’on attendait un tableau. Ces bugs silencieux coûtent des heures de débogage.

TypeScript résout ce problème en ajoutant une couche de vérification au moment de la compilation. Avant même que votre code ne s’exécute dans le navigateur, le compilateur détecte les incohérences. Concrètement, voici ce que cela change dans mon quotidien :

• Autocomplétion intelligente : mon éditeur connaît la forme exacte de chaque objet et me suggère les bonnes propriétés
• Refactoring sécurisé : quand je renomme une prop, TypeScript me signale immédiatement tous les composants impactés
• Documentation vivante : les types servent de documentation qui ne peut pas devenir obsolète, contrairement aux commentaires
• Détection précoce des bugs : les erreurs de type sont attrapées à l’écriture, pas en production

Si vous débutez en développement et souhaitez comprendre les bases, je vous recommande de consulter nos ressources pour apprendre à coder gratuitement avant de vous lancer dans TypeScript. Une bonne maîtrise de JavaScript reste un prérequis indispensable.

Pour bien comprendre les différences fondamentales entre ces deux langages, mon article sur TypeScript vs JavaScript vous donnera une base solide. TypeScript n’est pas un remplacement de JavaScript : c’est une extension qui compile vers du JavaScript standard.

TypeScript et React sont-ils la même chose

Non, et c’est une confusion que je rencontre régulièrement chez les développeurs juniors. React est une bibliothèque JavaScript créée par Meta (anciennement Facebook) pour construire des interfaces utilisateur. TypeScript, de son côté, est un langage de programmation développé par Microsoft qui ajoute le typage statique à JavaScript. Ce sont deux outils complémentaires, pas concurrents.

La question « lequel est le meilleur, React ou TypeScript » n’a donc pas vraiment de sens. C’est comme demander si un moteur est meilleur qu’un carburant : l’un fait tourner l’application (React gère le rendu et l’état), l’autre améliore la qualité du code qui la compose (TypeScript vérifie la cohérence des types). En pratique, on utilise TypeScript avec React, pas à la place de React.

On me demande aussi souvent la différence entre JSX et TSX. La réponse est simple : TSX est la version typée de JSX. Un fichier .tsx contient du code React avec des annotations de type TypeScript. Le comportement à l’exécution est strictement identique. La seule différence se situe au moment du développement, où TypeScript vérifie la cohérence de vos types avant la compilation.

Si vous hésitez entre React et d’autres frameworks, mon comparatif Vue.js contre React pourra vous aider à faire un choix éclairé selon votre contexte.

Configurer un projet React TypeScript

Il y a quelques années, configurer un projet React avec TypeScript demandait un travail manuel conséquent. Aujourd’hui, la plupart des outils modernes intègrent TypeScript nativement. Voici les trois méthodes que j’utilise selon le contexte du projet.

Avec Vite (ma recommandation en 2026)

Vite est devenu mon outil de prédilection pour démarrer un projet React. La configuration TypeScript est incluse par défaut :

npm create vite@latest mon-projet -- --template react-ts
cd mon-projet
npm install
npm run dev

En moins de 30 secondes, vous avez un projet React typé, avec un serveur de développement ultra-rapide et le hot module replacement. Vite utilise esbuild pour la transpilation, ce qui le rend significativement plus rapide que les alternatives basées sur Webpack.

Avec Next.js

Pour les projets qui nécessitent du rendu côté serveur, Next.js offre une intégration TypeScript irréprochable :

npx create-next-app@latest mon-projet --typescript
cd mon-projet
npm run dev

Next.js génère automatiquement le fichier tsconfig.json et installe les dépendances de types nécessaires. C’est la solution que je recommande pour les applications qui doivent être bien référencées.

Avec Create React App (déconseillé)

L’ancienne commande create-react-app --template typescript fonctionnait, mais le projet est officiellement en maintenance depuis fin 2023. Je vous déconseille de l’utiliser pour de nouveaux projets. Si vous avez un projet existant qui l’utilise, envisagez une migration vers Vite.

Pour exécuter ces commandes, vous aurez besoin de Node.js installé sur votre machine. Si vous êtes sous Linux, consultez mon guide pour installer Node.js sur Ubuntu.

Le fichier tsconfig.json essentiel

Quel que soit l’outil choisi, le fichier tsconfig.json contrôle le comportement du compilateur. Voici les options que j’active systématiquement dans mes projets React :

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "jsx": "react-jsx",
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true
  },
  "include": ["src"]
}

L’option strict: true est la plus importante. Elle active un ensemble de vérifications strictes qui détectent la majorité des erreurs courantes. Ne la désactivez jamais, même si cela demande plus de rigueur au début.

Typer les composants React correctement

Le typage des composants est la première compétence à maîtriser. En pratique, il existe deux grandes approches : les types explicites et l’inférence. Je privilégie un équilibre entre les deux.

Composants fonctionnels avec props typées

La méthode que j’utilise le plus souvent consiste à définir un type pour les props, puis à l’appliquer directement dans les paramètres de la fonction :

type ButtonProps = {
  label: string;
  variant: 'primary' | 'secondary' | 'danger';
  disabled?: boolean;
  onClick: () => void;
};

function Button({ label, variant, disabled = false, onClick }: ButtonProps) {
  return (
    <button
      className={`btn btn-${variant}`}
      disabled={disabled}
      onClick={onClick}
    >
      {label}
    </button>
  );
}

Remarquez l’utilisation d’une union littérale pour la prop variant. C’est bien plus sûr qu’un simple string : le compilateur refusera toute valeur qui n’est pas dans la liste autorisée. Pour approfondir le sujet des types en TypeScript, consultez mon guide sur les interfaces en TypeScript.

React.FC : à éviter dans la plupart des cas

Beaucoup de tutoriels utilisent encore React.FC (ou React.FunctionComponent). Après des années d’utilisation, je ne le recommande plus pour plusieurs raisons :

• Il ajoutait historiquement children de manière implicite (corrigé dans React 18, mais l’habitude reste)
• Il ne supporte pas les génériques facilement
• Il ajoute de la verbosité sans réel bénéfice

La communauté React, y compris la documentation officielle de React, recommande désormais le typage direct des paramètres.

Typer les children

Si votre composant accepte des enfants, typez-les explicitement avec React.ReactNode :

type CardProps = {
  title: string;
  children: React.ReactNode;
};

function Card({ title, children }: CardProps) {
  return (
    <div className="card">
      <h3>{title}</h3>
      <div className="card-body">{children}</div>
    </div>
  );
}

React.ReactNode accepte du texte, des éléments JSX, des tableaux, des fragments, null et undefined. C’est le type le plus flexible pour les children.

Hooks et TypeScript : les bonnes pratiques

Les hooks de React fonctionnent remarquablement bien avec TypeScript grâce à l’inférence de types. Dans la majorité des cas, vous n’avez pas besoin d’annoter manuellement. Mais il existe des situations où le typage explicite est nécessaire.

useState

Pour les valeurs simples, l’inférence suffit :

const [count, setCount] = useState(0); // TypeScript infère number
const [name, setName] = useState(''); // TypeScript infère string

Mais quand la valeur initiale est null ou quand le type est plus complexe, il faut être explicite :

type User = {
  id: number;
  name: string;
  email: string;
};

const [user, setUser] = useState<User | null>(null);

// Plus tard, après un appel API
setUser({ id: 1, name: 'Thomas', email: '[email protected]' });

useRef

Le hook useRef est l’un des plus délicats à typer. La règle est simple : si la ref pointe vers un élément DOM, passez null comme valeur initiale :

const inputRef = useRef<HTMLInputElement>(null);

// Dans le JSX
<input ref={inputRef} type="text" />

// Utilisation (avec vérification de nullité)
if (inputRef.current) {
  inputRef.current.focus();
}

useReducer

C’est avec useReducer que TypeScript brille le plus. Les unions discriminées permettent de typer chaque action de manière exhaustive :

type State = {
  items: string[];
  loading: boolean;
  error: string | null;
};

type Action =
  | { type: 'FETCH_START' }
  | { type: 'FETCH_SUCCESS'; payload: string[] }
  | { type: 'FETCH_ERROR'; error: string };

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'FETCH_START':
      return { ...state, loading: true, error: null };
    case 'FETCH_SUCCESS':
      return { ...state, loading: false, items: action.payload };
    case 'FETCH_ERROR':
      return { ...state, loading: false, error: action.error };
  }
}

Avec ce pattern, TypeScript garantit que chaque branche du switch accède uniquement aux propriétés qui existent pour ce type d’action. Si vous oubliez un cas, le compilateur vous prévient.

useContext avec typage fort

Le contexte React bénéficie grandement du typage. Voici le pattern que j’utilise systématiquement :

type ThemeContextType = {
  theme: 'light' | 'dark';
  toggleTheme: () => void;
};

const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

function useTheme() {
  const context = useContext(ThemeContext);
  if (context === undefined) {
    throw new Error('useTheme doit être utilisé dans un ThemeProvider');
  }
  return context;
}

Ce hook personnalisé useTheme garantit que le contexte n’est jamais undefined dans les composants qui l’utilisent. C’est une pratique que je recommande pour chaque contexte de votre application.

Gestion des événements et formulaires typés

La gestion des événements est un point où beaucoup de développeurs trébuchent avec TypeScript. Le secret est de connaître les types d’événements fournis par React.

Événements courants

function SearchForm() {
  const [query, setQuery] = useState('');

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setQuery(e.target.value);
  };

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    console.log('Recherche :', query);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        value={query}
        onChange={handleChange}
        placeholder="Rechercher..."
      />
      <button type="submit">Valider</button>
    </form>
  );
}

Les types d’événements les plus utilisés dans mes projets sont :

Pour les formulaires complexes, pensez à l’accessibilité web dès le départ. TypeScript vous aide à ne pas oublier les attributs aria-* si vous les incluez dans vos types de props.

Astuce : laisser TypeScript inférer le type d’événement

Quand vous passez le handler directement dans le JSX (inline), TypeScript infère automatiquement le type :

<input
  onChange={(e) => {
    // e est automatiquement typé React.ChangeEvent<HTMLInputElement>
    setQuery(e.target.value);
  }}
/>

Le typage explicite n’est nécessaire que lorsque vous définissez la fonction en dehors du JSX.

Patterns avancés TypeScript React

Une fois les bases maîtrisées, certains patterns avancés permettent de créer des composants à la fois flexibles et parfaitement typés. Ce sont ces techniques qui font la différence entre un projet « typé par-dessus » et un projet où TypeScript apporte une réelle valeur ajoutée.

Composants génériques

Les génériques permettent de créer des composants réutilisables sans perdre l’information de type :

type ListProps<T> = {
  items: T[];
  renderItem: (item: T) => React.ReactNode;
  keyExtractor: (item: T) => string;
};

function List<T>({ items, renderItem, keyExtractor }: ListProps<T>) {
  return (
    <ul>
      {items.map((item) => (
        <li key={keyExtractor(item)}>{renderItem(item)}</li>
      ))}
    </ul>
  );
}

// Utilisation : TypeScript infère T comme User
<List
  items={users}
  renderItem={(user) => <span>{user.name}</span>}
  keyExtractor={(user) => user.id.toString()}
/>

Ce pattern est particulièrement utile pour les composants de type tableau, sélecteur, ou liste. Pour aller plus loin avec les structures de données typées, mon guide sur Map en TypeScript couvre les collections clé-valeur en détail.

Unions discriminées pour les états d’interface

Plutôt que de gérer des combinaisons de booléens (loading, error, data), je modélise les états de l’interface comme des unions discriminées :

type AsyncState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: string };

function UserProfile({ state }: { state: AsyncState<User> }) {
  switch (state.status) {
    case 'idle':
      return <p>En attente...</p>;
    case 'loading':
      return <Spinner />;
    case 'success':
      return <h2>{state.data.name}</h2>; // data est garanti ici
    case 'error':
      return <p className="error">{state.error}</p>; // error est garanti ici
  }
}

Ce pattern élimine les états impossibles. Vous ne pouvez pas avoir loading: true et data défini en même temps. C’est l’un des avantages les plus puissants de TypeScript dans un projet React.

Types utilitaires essentiels

TypeScript fournit des types utilitaires qui simplifient considérablement le typage des composants React. Voici ceux que j’utilise le plus, documentés dans le handbook officiel de TypeScript :

// Rendre certaines props optionnelles
type EditUserProps = Partial<User> & { onSave: (user: User) => void };

// Sélectionner un sous-ensemble de props
type UserSummary = Pick<User, 'id' | 'name'>;

// Exclure certaines props
type PublicUser = Omit<User, 'email' | 'password'>;

// Record pour les objets indexés
type Permissions = Record<string, boolean>;

Pour une exploration approfondie du type Record, consultez mon article dédié sur Record en TypeScript.

Erreurs courantes et solutions

Après avoir accompagné des dizaines de développeurs dans leur transition vers TypeScript avec React, je retrouve systématiquement les mêmes erreurs. Voici comment les éviter.

Erreur n°1 : utiliser any partout

C’est la tentation la plus fréquente. Quand TypeScript râle, on ajoute : any et le problème disparaît. Sauf que vous venez de désactiver exactement la protection que TypeScript est censé apporter. Si vous ne savez pas quel type utiliser, préférez unknown qui vous obligera à vérifier le type avant utilisation.

Erreur n°2 : ne pas activer le mode strict

Sans strict: true dans le tsconfig.json, TypeScript est bien trop permissif. Cette option active notamment strictNullChecks, qui est essentiel pour détecter les erreurs liées à null et undefined. Sur un projet existant, activez-le progressivement fichier par fichier si nécessaire.

Erreur n°3 : sur-typer

À l’inverse, certains développeurs annotent absolument tout, y compris ce que TypeScript peut inférer seul. Cela crée du bruit et rend le code moins lisible. Règle simple : typez les entrées (props, paramètres), laissez TypeScript inférer les sorties (valeurs de retour, variables locales).

Erreur n°4 : ignorer les assertions de type non-null

L’opérateur ! (non-null assertion) est un piège. Il dit à TypeScript « fais-moi confiance, cette valeur n’est jamais null ». C’est presque toujours un mensonge. Préférez les guards (if de vérification) ou le chaînage optionnel (?.).

Erreur n°5 : confondre type et interface

Pour les props de composants React, les deux fonctionnent. Ma convention : type pour les props et les unions, interface pour les contrats publics d’API. L’essentiel est d’être cohérent dans tout le projet.

React est-il encore pertinent en 2026

C’est une question qui revient chaque année, et la réponse en 2026 reste clairement oui. React continue de dominer le marché des bibliothèques frontend avec une part estimée à plus de 40 % des applications web en production, selon les données de la Developer Survey de Stack Overflow.

Plusieurs facteurs expliquent cette longévité :

• L’écosystème React Server Components a considérablement mûri, offrant des performances comparables aux frameworks « full-stack » tout en gardant la flexibilité de React
• Next.js, Remix et les meta-frameworks continuent de proposer des solutions de production robustes, ce qui rassure les entreprises
• Le marché de l’emploi reste très favorable aux développeurs React. En France, c’est toujours la compétence frontend la plus demandée
• L’intégration native avec TypeScript a renforcé la confiance des équipes dans la maintenabilité des projets React à grande échelle

Pour les développeurs qui souhaitent se lancer en freelance avec ces compétences, notre guide sur les missions freelance en informatique détaille comment valoriser ce type d’expertise sur le marché.

Cela dit, l’écosystème évolue. Des alternatives comme Svelte, Solid ou Qwik progressent. Mais la masse critique de React, son écosystème de bibliothèques, et le nombre de développeurs formés en font un choix sûr pour les années à venir. Ce qui change, c’est que TypeScript n’est plus optionnel : la quasi-totalité des nouveaux projets React en entreprise démarrent en TypeScript.