Erreurs courantes de TypeScript dans React et comment les résoudre

Si vous venez de JavaScript, TypeScript peut sembler intimidant au début. Au cours des premiers jours, il peut paraître que le compilateur travaille activement contre vous : des lignes ondulées rouges et jaunes partout, des messages énigmatiques qui semblent ne mener nulle part... et à un moment donné, vous pourriez commencer à vous demander si passer à TypeScript était vraiment une bonne idée, se demandant si revenir au JavaScript pur ne serait pas plus simple.

Cependant, voici le fait : intégrer TypeScript dans une base de code React est l’un des choix les plus judicieux que vous puissiez faire si vous tenez à maintenir une qualité de code sur le long terme.

Et ces erreurs et avertissements auxquels vous êtes constamment confronté ? Ils valent absolument la peine d’être surmontés, il vous suffit d’apprendre à reconnaître les schémas récurrents qui se cachent derrière eux.

La plupart des problèmes avec TypeScript que vous rencontrez lors du développement d’applications React ne sont pas du tout aléatoires. Les mêmes erreurs réapparaissent sans cesse dans différents projets, et une fois que vous les aurez traitées à plusieurs reprises, vous commencerez à les repérer instantanément et à comprendre exactement ce qu’elles signifient. Cet article passe en revue cinq catégories d’erreurs que l’on retrouve dans presque tous les projets React utilisant TypeScript, en expliquant pourquoi chacune se produit et comment la résoudre.

Un conseil avant de commencer : lisez toujours le message d’erreur dans son intégralité. Les erreurs de TypeScript peuvent sembler effrayantes au premier abord, mais elles suivent en réalité une structure assez prévisible. Ne laissez pas cette masse de texte vous déstabiliser ; si vous ne savez pas par où commencer, la dernière ligne du message est généralement la partie la plus utile à examiner.

Avec cela dit, passons au sujet.

1. Erreurs liées aux props des composants

Les props constituent le cœur de chaque composant React, il est donc logique que les erreurs de type liées aux props soient généralement les premières auxquelles se heurtent les développeurs.

L’erreur : La propriété ‘X’ n’existe pas dans le type '{}'.

Cette erreur apparaît lorsque vous utilisez un prop dans votre composant sans jamais en définir le type.

// This won't give any errors in JavaScript...
function UserCard({ name, email }) {
  return (
    <div>
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
};

// But in TypeScript...
// Error: Parameter 'name' implicitly has an 'any' type
// Error: Parameter 'email' implicitly has an 'any' type

Cette erreur apparaît simplement parce que les props n’ont jamais reçu de types explicites.

La solution : déclarer une interface décrivant vos props.

interface UserCardProps {
  name: string;
  email: string;
};

function UserCard({ name, email}: UserCardProps) {
  return (
    <div>
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
};

L’erreur : Le type ‘string’ n’est pas assignable au type ‘number’.

Cette erreur est assez simple à comprendre : elle signifie que vous avez passé un prop avec une valeur du mauvais type.

La solution : vérifier le type de la valeur que vous passez au prop.

interface ItemForSaleProps {
  imgUrl: string;
  itemName: string;
  amount: number;
  currency: string;
};

function ItemForSale({
  itemName,
  imgUrl,
  amount,
  currency
}: ItemForSaleProps) {
  return (
    <div class="item-for-sale">
      <img src={imgUrl} alt="item image" />
      <h5>{itemName}</h5>
      <p>{`${currency} ${amount.toFixed(2)}`}</p>
    </div>
  );
};

// Error happens when passing a string where a number is expected.
<ItemForSale
  imgUrl="api.example.com/image"
  itemName="Sample"
  amount="10.99"
  currency="USD"
/>

// Should be like this
<ItemForSale
  imgUrl="api.example.com/image"
  itemName="Sample"
  amount={10.99}
  currency="USD"
/>

Remarquez la différence entre les deux versions ? Le composant ItemForSale attend que amount soit de type number ; par conséquent, la transmission d’une chaîne de caractères provoque une erreur, tandis que l’envoi d’une valeur numérique réelle est correct. C’est là que TypeScript fait exactement ce pour quoi il a été conçu : détecter d’éventuels bugs avant même que votre code ne s’exécute. Dans cet exemple, l’appel à .toFixed(2) sur la chaîne '10.99' provoquerait en réalité une panne à l’exécution, mais TypeScript signale le problème pendant la compilation.

L’erreur : La propriété 'X' est absente dans le type '{}' mais requise dans le type 'Props'.

Cela se produit lorsque une propriété est déclarée comme obligatoire dans votre interface, mais que vous oubliez de la transmettre lors de l’utilisation du composant.

interface CustomButtonProps {
  label: string;
  onClick: () => void;
};

function CustomButton({ label, onClick }: CustomButtonProps) {
  return <button onClick={onClick}>{label}</button>;
};

// Bad usage:
<CustomButton label="Submit" />
// Error: Property 'onClick' is missing in type '{ label: string; }'
// but required in type 'ButtonProps'

La solution :vérifiez à nouveau les définitions des propriétés dans votre composant ainsi que celles que vous fournissez réellement lors de leur rendu.

// Correct usage:
<CustomButton label="Submit" onClick={handleSubmit} />

Parfois, vous avez des propriétés qui ne sont pas toujours nécessaires. Dans ces cas, vous pouvez indiquer qu’une propriété est optionnelle en utilisant un ?. N’oubliez pas que lorsque vous faites d’une propriété une valeur optionnelle, vous devez également fournir une valeur par défaut ou un mécanisme de vérification pour gérer son absence en toute sécurité.

interface CustomButtonProps {
  label: string;
  onClick: () => void;
  disabled?: boolean;   // this prop is now optional
  className?: string;   // this one too
};

function CustomButton({ label, onClick, disabled = false, className }: CustomButtonProps) {
  return (
    <button
      onClick={onClick}
      disabled={disabled}
      className={className}
    >
      {label}
    </button>
  );
};

// This component now works with or without the optional props
<CustomButton label="Submit" onClick={handleSubmit} />
<CustomButton label="Submit" onClick={handleSubmit} disabled={true} />

Maintenant que les propriétés optionnelles sont prises en compte, il y a une autre erreur à mentionner.

L’erreur : Le type ‘X | undefined’ ne peut pas être assigné au type ‘X’.

Faire d’une propriété une valeur optionnelle ajoute automatiquement undefined à son type, ce qui pose des problèmes si vous tentez d’utiliser cette valeur sans d’abord vérifier son existence.

interface ProfileProps {
  name: string;
  bio?: string;
};

function Profile({ name, bio }: ProfileProps) {
  return (
    <p>{name}</p>
    <p>{bio.toUpperCase()}</p>
    // Error: Object is possibly 'undefined'
  );
};

En général, vous avez trois façons de gérer cela :

Option 1 : fournir une valeur par défaut lors de la déstructuration des props.

// bio is always a string, will render a default text when there's
// no bio provided
function Profile({ name, bio = 'No bio available' }: ProfileProps) {
  return (
    <p>{name}</p>
    <p>{bio.toUpperCase()}</p>
  );
};

Option 2 : utiliser la chaînage optionnel.

// returns undefined if bio is undefined
function Profile({ name, bio }: ProfileProps) {
  return (
    <p>{name}</p>
    <p>{bio?.toUpperCase()}</p>
  );
};

Option 3 : utiliser le rendu conditionnel.

// will only render if bio exists
function Profile({ name, bio }: ProfileProps) {
  return (
    <p>{name}</p>
    <p>{bio && bio.toUpperCase()}</p>
  );
};

2. Erreurs des gestionnaires d’événements

Toute composante React qui réagit aux interactions de l’utilisateur a besoin de gestionnaires d’événements, et TypeScript propose des types très précis pour chaque type d’événement DOM. Se tromper dans ces types est l’une des causes les plus fréquentes de confusion chez les développeurs travaillant avec du code React typé.

Le problème : le paramètre ‘e’ a implicitement un type ‘any’.

Cela se produit lorsque vous écrivez un gestionnaire d’événements en tant que fonction indépendante en dehors de votre JSX et oubliez d’annoter le paramètre d’événement.

// Error: Parameter 'e' implicitly has an 'any' type
const handleClick = (e) => {
  e.preventDefault();
};

La solution : Associez le type d’événement React correspondant au paramètre.

const handleClick = (e: React.MouseEvent<HTMLButtonElement>) => {
  e.preventDefault();
};

À noter : lorsque vous écrivez directement le gestionnaire d’événements à l’intérieur de votre JSX, TypeScript peut déterminer le type par lui-même, ce qui fait que cette erreur en particulier n’apparaîtra pas dans ce cas.

<button onClick={(e) => {
  e.preventDefault() // e is automatically React.MouseEvent<HTMLButtonElement>
}}>
  Click here
</button>

Le problème : La propriété ‘value’ n’existe pas sur le type ‘EventTarget’.

Ce peut être l’erreur TypeScript la plus recherchée parmi les développeurs React — c’est aussi l’une des plus difficiles à comprendre la première fois qu’on la rencontre. Elle apparaît lorsque vous essayez de lire e.target.value à l’intérieur d’un gestionnaire de changement.

// This will give an error because TS doesn't know target is an input element.
const handleChange = (e: React.ChangeEvent) => {
  console.log(e.target.value);
  // Error: Property 'value' does not exist on type 'EventTarget'
};

La cause racine est que EventTarget est une interface DOM générique, de sorte que TypeScript ne peut pas savoir qu, dans ce gestionnaire particulier, la cible est en réalité un élément <input> qui expose par hasard une propriété value.

La solution : Fournir le type d’élément spécifique en tant que paramètre générique pour le type d’événement.

// TypeScript now knows the target is an HTMLInputElement
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  console.log(e.target.value);
};

Le même schéma fonctionne pour d’autres éléments — pour un élément select, par exemple, remplacez HTMLInputElement par HTMLSelectElement. Voici un répertoire rapide des types d’événements que vous utiliserez le plus souvent :

// Click events
onClick: (e: React.MouseEvent<HTMLButtonElement>) => void
onClick: (e: React.MouseEvent<HTMLDivElement>) => void

// Input change events
onChange: (e: React.ChangeEvent<HTMLInputElement>) => void
onChange: (e: React.ChangeEvent<HTMLSelectElement>) => void
onChange: (e: React.ChangeEvent<HTMLTextAreaElement>) => void

// Form submission
onSubmit: (e: React.FormEvent<HTMLFormElement>) => void

// Keyboard events
onKeyDown: (e: React.KeyboardEvent<HTMLInputElement>) => void
onKeyUp: (e: React.KeyboardEvent<HTMLInputElement>) => void

// Focus events
onFocus: (e: React.FocusEvent<HTMLInputElement>) => void
onBlur: (e: React.FocusEvent<HTMLInputElement>) => void

Puisque nous parlons des gestionnaires d’événements, vous vous demandez peut-être comment les écrire correctement lorsqu’on les transmet comme props aux composants enfants. Dans ce cas, ils doivent être définis comme des fonctions qui acceptent l’objet d’événement approprié.

interface SearchInputProps {
  onSearch: (e: React.ChangeEvent<HTMLInputElement>) => void;
  onSubmit: (e: React.FormEvent<HTMLFormElement>) => void;
};

function SearchInput({ onSearch, onSubmit }: SearchInputProps) {
  return (
    <form onSubmit={onSubmit}>
      <input type="text" onChange={onSearch} />
      <button type="submit">Search</button>
    </form>
  );
};

Et si un gestionnaire donné n’a pas besoin du tout de recevoir l’événement, vous pouvez simplifier son type en conséquence.

interface SearchInputProps {
  onClick: () => void;
  onHover: () => void;
};

3. useState et useRef

Les hooks occupent une place centrale dans le développement React moderne, il n’est donc pas surprenant que useState et useRef présentent leurs propres particularités en TypeScript.

Le problème : Un argument de type ‘X’ ne peut pas être assigné à un paramètre de type ‘never’.

C’est l’un des erreurs les plus déroutantes auxquelles on peut être confronté. Elle se produit lorsque l’on initialise useState avec un tableau vide, ce qui amène TypeScript à déduire que le type de l’état est never[]. Voici à quoi cela ressemble :

// TypeScript infers state type as never[]
const [items, setItems] = useState([]);

// So later when we try to set a value...
setItems([{ id: 1, name: 'Item 1' }]);
// Error: Argument of type '{ id: number; name: string; }[]' is not assignable
// to parameter of type 'never[]'

La raison en est la suivante : lorsque la valeur initiale de votre état est un tableau vide, TypeScript ne peut pas deviner quel type d’éléments y seront finalement stockés, il choisit donc par défaut le type never[].

La solution : Indiquez toujours un argument de type explicite lorsque votre état initial est un tableau vide ou null.

interface Item {
  id: number;
  name: string;
}

// ✅ Explicitly typed
const [items, setItems] = useState<Item[]>([]);
const [selectedItem, setSelectedItem] = useState<Item | null>(null);

Dans cet extrait, le type de l’état selectedItem est explicitement défini pour accepter soit un objet Item, soit null. Chaque fois que vous prévoyez qu’un état commence vide et sera rempli ultérieurement, vous devez le préciser pour TypeScript — sinon vous rencontrerez cette erreur :

Le type ‘null’ ne peut pas être assigné au type ‘X’.

interface User {
  id: number;
  name: string;
  email: string;
}

// TypeScript infers state as User, not User | null
const [user, setUser] = useState<User>({} as User); // Dangerous cast

// Later...
if (user.name) { /* ... */ }
// This might not catch the case where user is empty

La solution : Utilisez un type union qui inclut null afin que TypeScript comprenne que les données ne sont pas encore chargées.

// Correctly typed, can be type User or null
const [user, setUser] = useState<User | null>(null);

// Now TypeScript forces you to handle the null case
if (user) {
  console.log(user.name); // TypeScript knows user is User here
}

// Or with optional chaining:
console.log(user?.name); // string | undefined

La même logique s’applique lorsque votre état contient un objet plus complexe. Supposons que vous modélisiez l’état d’un formulaire de contact avec plusieurs champs — l’approche correcte consiste d’abord à définir une interface décrivant cette structure.

interface FormState {
  name: string;
  email: string;
  message: string;
  isSubmitting: boolean;
}

function SubmitMessageForm() {
  const [form, setForm] = useState<FormState>({
    name: '',
    email: '',
    message: '',
    isSubmitting: false,
  });

  // Then do partial updates with spread operator
  const handleChange = (field: keyof FormState, value: string) => {
    setForm(prevState => ({ ...prevState, [field]: value }));
  };
}

Le problème : L’objet peut être ‘null’.

Ce problème apparaît constamment lorsque une référence créée avec useRef commence par valoir null alors qu’elle devrait pointer vers un élément DOM. TypeScript signale toute tentative d’utiliser cette référence avant de confirmer qu’elle contient réellement une valeur.

const inputRef = useRef<HTMLInputElement>(null);

// Typescript here knows that inputRef.current might be null
inputRef.current.focus();

// Error: Object is possibly 'null'

La solution : vérifier que current a bien été définie avant de l’utiliser. Dès que TypeScript détecte cette vérification, il cesse de signaler l’erreur car il ne peut plus prouver que la valeur pourrait être null.

// Null check before use
const handleFocus = () => {
  if (inputRef.current) {
    inputRef.current.focus();
  }
};

// Or if you're more into one-liners, you can use optional chaining
inputRef.current?.focus();

Au moment de passer à la catégorie suivante, il y a un changement important qu’il convient de souligner. React 19 a modifié le comportement de useRef d’une manière qui pose des problèmes à de nombreux développeurs — plus précisément, la distinction entre RefObject<T|null> et MutableRefObject<T>. Ce qui détermine désormais le comportement n’est plus la valeur initiale que vous passez, mais le paramètre de type générique que vous fournissez à l’hook.

Au préalable à React 19, l’appel de useRef(null) renvoyait toujours un MutableRefObject<T>, ce qui permettait donc toujours de réaffecter la valeur de current.

// This worked fine
const ref = useRef<HTMLInputElement | null>(null);
ref.current = someElement;

Dès React 19, le type générique que vous spécifiez détermine si current est écrivable.

const ref = useRef<HTMLInputElement>(null);
ref.current = someElement;
// The above will result in an error.

Ici, comme le paramètre générique est un type d’élément HTML, React 19 traite le ref comme s’il pointait vers le DOM, ce qui en fait un élément en lecture seule géré par React lui-même.

Si vous avez besoin d’un ref pour stocker une valeur mutable plutôt qu’un nœud DOM, faites ceci :

// Let's suppose we're building a timer
const ref = useRef<ReturnType<typeof setTimeout> | null>(null);
ref.current = setTimeout(() => {}, 1000);

Cela fonctionne parce que le type passé au paramètre générique n’est pas un type d’élément HTML, donc React le traite comme un ref mutable ordinaire — current reste modifiable.

Règle pour React 19 : lorsque le type générique est un type d’élément HTML, current devient en lecture seule et est contrôlé par React. Lorsqu’il s’agit d’un autre type, current reste modifiable. En bref :

• useRef<HTMLElement>(null) pour les nœuds DOM gérés par React (en lecture seule)

useRef<T|null>(null) pour toute autre valeur mutable que vous souhaitez stocker vous-même

4. Données asynchrones et erreurs API

Lorsque vous commencez à récupérer des données depuis une API, un nouveau ensemble d’erreurs TypeScript apparaît, car les données récupérées commencent par être de type unknown et doivent subir plusieurs transformations avant de devenir quelque chose que vous pouvez utiliser en toute sécurité.

L’erreur : Le type ‘unknown’ ne peut pas être assigné au type ‘X’.

Par défaut, le résultat d’une requête fetch est de type unknown, car TypeScript ne dispose d’aucune information intégrée sur la forme des données retournées par un endpoint donné.

// Fetch response is unknown
const response = await fetch('/api/users');
const data = await response.json(); // data: any (in older TS) or unknown

// So when trying to use the fetched data:
const userName = data.name;

// With the code above, you might get a warning, something like
// 'data' is of type 'unknown'

La solution : déclarer un type explicite pour la réponse de votre API.

interface User {
  id: number;
  name: string;
  email: string;
};

À partir de là, vous avez généralement deux options pour appliquer ce type :

// Option 1: Type assertion. Only use this when you trust the API shape.
const response = await fetch('/api/users/1');
const data = await response.json() as User;
console.log(data.name); // You'll see that you have a string here

//////////////////////////////////////////////////////////////////////////

// Option 2: Create a generic fetch wrapper, this is a safer approach
// and it's reusable.
async function fetchJSON<T>(url: string): Promise<T> {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`HTTP error: ${response.status}`);
  }
  return response.json() as Promise<T>;
}
const user = await fetchJSON<User>('/api/users/1');
console.log(user.name); // TypeScript now knows this is a string

5. Enfants et erreurs JSX

Les composants React acceptent et affichent régulièrement des children, et TypeScript propose plusieurs types qui se recoupent pour décrire ce que peuvent être ces enfants. Connaître leurs différences vous aide à éviter toute une série d’erreurs de type.

Trois types sont souvent utilisés comme s’ils étaient interchangeables, alors qu’ils ne le sont pas :

• ReactNode
• ReactElement
• JSX.Element

Parmi ceux-ci, ReactNode et ReactElement sont véritablement distincts, tandis que JSX.Element n’est en réalité qu’un autre nom pour ReactElement.

import { ReactNode, ReactElement } from 'react';

// ReactNode is the most permissive one, accepts basically
// everything React can render:
// string, number, boolean, null, undefined, ReactElement, arrays...

type ReactNode =
  | ReactElement
  | string
  | number
  | boolean
  | null
  | undefined
  | ReactPortal
  | Iterable<ReactNode>;

// ReactElement is literally a React element created by
// JSX or React.createElement
// It does not include string, number, null, undefined
type ReactElement = {
  type: string | ComponentType;
  props: any;
  key: string | null;
};

En règle générale : optez pour ReactNode comme type par défaut pour la propriété children, sauf si vous avez une raison concrète de la restreindre.

// Most flexible: use ReactNode for children in most cases
interface CardProps {
  children: ReactNode;
};

// And use ReactElement when the requirements are not very flexible
interface StrictWrapperProps {
  children: ReactElement;
};

Il convient d’expliquer plus précisément la différence entre ReactNode et ReactElement.

ReactNode peut ressembler à n’importe lequel de ces éléments :

const example1 = <div>Hello</div>;        // ReactElement ✅
const example2 = "Hello";                 // string ✅
const example3 = 42;                      // number ✅
const example4 = true;                    // boolean ✅ (renders nothing)
const example5 = null;                    // null ✅ (renders nothing)
const example6 = undefined;               // undefined ✅ (renders nothing)
const example7 = [<div />, <span />];     // array of ReactElements ✅

// All of the above are ReactNode

D’un autre côté, un ReactElement est plus restreint :

const example1 = <div>Hello</div>;
const example2 = <Button onClick={someHandlerFn}>Submit</Button>;
const example3 = React.createElement('div', null, 'Hello');

// Under the hood, every ReactElements look like this:
{
  type: 'div',
  props: { children: 'Hello' },
  key: null,
}

L’erreur : Le type ‘X’ n’est pas assignable au type ‘ReactNode’.

Cela se produit généralement lorsque l’on tente de rendre une valeur que TypeScript ne reconnaît pas comme du contenu pouvant être affiché.

// Objects are not a valid React children
interface User {
  name: string;
  email: string;
}


// Then if you try to do this
function DisplayUser({ user }: { user: User }) {
  return <div>{user}</div>;
}

// It'll probably give you an error that looks something like...
// Error: Type 'User' is not assignable to type 'ReactNode'
// Objects are not valid React Children

La solution : rendre les champs individuels plutôt que l’objet entier.

function DisplayUser({ user }: { user: User }) {
  return (
    <div>
      <p>{user.name}</p>
      <p>{user.email}</p>
    </div>
  );
}

L’erreur : Le type d’élément JSX ‘X’ ne possède aucune signature de construction ou d’appel.

Cela peut sembler confus au début. Ce problème apparaît lorsque vous passez une valeur quelque part en espérant qu’elle se comporte comme un composant, mais TypeScript n’a aucun moyen de confirmer qu’il s’agit bien d’un composant.

// TypeScript doesn't know 'icon' is a valid component
interface ButtonProps {
  icon: object; // too vague
};

// So when you try this...
function Button({ icon: Icon }: ButtonProps) {
  return <Icon />;
}

// The above code will give you the error
// Error: JSX element type 'Icon' does not have any construct
// or call signatures

La solution : typisez les composants dynamiques avec React.ComponentType:

import { ComponentType } from 'react';

interface ButtonProps {
  icon: ComponentType;
};

function Button({ icon: Icon }: ButtonProps) {
  return (
    <button>
      <Icon />
    </button>
  );
}

// TypeScript now knows Icon is a valid component

Si ce composant prend également des props, vous pouvez les décrire explicitement :

interface IconProps {
  size?: number;
  color?: string;
};

interface ButtonProps {
  icon: ComponentType<IconProps>;
};

function Button({ icon: Icon }: ButtonProps) {
  return (
    <button>
      <Icon size={12} color="white" />
    </button>
  );
}

// So now the props are typed too

Un raccourci utile à connaître est le type d’outil intégré de React, PropsWithChildren. Il ajoute automatiquement children?: ReactNode à n’importe quelle interface de props autour de laquelle il est utilisé, vous évitant ainsi de devoir déclarer à nouveau ce champ à chaque fois :

import { PropsWithChildren } from 'react';

// Now instead of doing this
interface CardProps {
  title: string;
  children?: ReactNode;
};

// You can do this
type CardProps = PropsWithChildren<{ title: string }>;

// So with this, instead of explicitly typing children manually,
// you can use the above code

function Card({ title, children }: CardProps) {
  return (
    <div>
      <h1>{title}</h1>
      <div>{children}</div>
    </div>
  );
}

Le problème : affichage de listes d’éléments

TypeScript impose des règles strictes concernant les clés dans les listes affichées, mais la plupart des erreurs de type que vous rencontrerez proviennent en réalité du fait de la manière dont les éléments eux-mêmes sont définis en termes de types, et non des clés.

// Items might be undefined, or item.id might not be a valid key type
function ItemList({ items }: { items: Item[] | undefined }) {
  return (
    <ul>
      {
        items.map(item => (
          <li key={item.id}>{item.name}</li>
        ))
      }
    </ul>
  );
}

// Error: Object is possibly 'undefined'

La solution : protéger contre les valeurs undefined et s’assurer que la définition des types est correcte :

function ItemList({ items = [] }: { items?: Item[] }) {
  return (
    <ul>
      {
        items.map((item) => (
          <li key={item.id}>{item.name}</li>
        ))
      }
    </ul>
  );
}

Pour terminer…

Les erreurs de TypeScript cessent d’être perçues comme des obstacles dès que vous commencez à les considérer comme des indices. Ce changement d’attitude survient au moment où vous cessez de réagir avec « pff, pas encore ça » et commencez plutôt à vous demander « qu’est-ce que TypeScript essaie vraiment de me dire ici ? »

Les erreurs abordées dans ce guide sont celles que vous rencontrerez constamment au cours de votre travail avec React et TypeScript. Ce qui distingue un développeur qui lutte constamment contre le système de types d’un autre qui travaille confortablement avec lui réside généralement dans la capacité à reconnaître des schémas, rien de plus. À ce stade, vous maîtrisez ces schémas.