Composants Fonctions vs React.FC en TypeScript : Un Dialogue Civilisé

Comprendre l'évolution du typage TypeScript dans les composants React

Composants Fonctions vs React.FC en TypeScript : Un Dialogue Civilisé

React et TypeScript entrent ensemble dans un projet. TypeScript dit : « Je gère les types. » React répond : « Je m'occupe du rendu. » Et quelque part en chemin, quelqu'un demande :

Faut-il utiliser React.FC ou simplement typer la fonction directement ?

C'est une question raisonnable. À première vue, React.FC semble élégant, officiel – même sophistiqué. Comme s'il pouvait vous servir un verre de vin en disant « Rendons ce composant élégant. » Mais sous la surface, il traîne quelques bagages que TypeScript moderne a en grande partie dépassés.

Regardons cela de plus près.

Les Deux Styles

Le Composant Fonction Simple

type Props = { title: string };

function MyComponent({ title }: Props) {
  return <h1>{title}</h1>;
}

Propre, clair, et facile à comprendre. Comme un café noir : sans artifices, juste efficace.

Ou, si vous préférez les fonctions fléchées :

const MyComponent = ({ title }: Props) => {
  return <h1>{title}</h1>;
};

Les deux sont valides, lisibles, et parfaitement alignés avec les bonnes pratiques actuelles.

La Variante React.FC

import { FC } from 'react';

type Props = { title: string };

const MyComponent: FC<Props> = ({ title }) => {
  return <h1>{title}</h1>;
};

Cette version enveloppe le composant avec un type générique. Cela paraît plus « officiel », et si vous avez récemment découvert les types utilitaires de TypeScript, cela peut sembler naturel – comme si vous aviez débloqué un club privé. Mais parfois, ces clubs ont leurs petites restrictions.

Ce Que Fait Réellement React.FC

React.FC (abréviation de React.FunctionComponent) est un type helper qui décrit un composant fonctionnel. Il offre quelques comportements par défaut :

  • Il inclut la prop children par défaut, que vous le vouliez ou non.
  • Il peut parfois améliorer l'autocomplétion dans certains éditeurs.
  • Il peut rendre le type de retour de la fonction un peu plus explicite, bien que cela importe rarement en pratique.

Ce sont des commodités modestes, et à l’époque où React + TypeScript étaient moins matures, elles étaient plus utiles. Mais les temps ont changé, et aujourd’hui, ces « fonctionnalités » gênent souvent plus qu’elles n’aident.

Pourquoi Il Perd en Popularité

On pourrait dire que React.FC est le pantalon cargo de TypeScript — plein de poches, dont la plupart restent vides.

  1. children implicite

Chaque composant reçoit une prop children même s’il ne la souhaite pas. Cela peut provoquer des bugs déroutants quand les développeurs supposent que children sont valides simplement parce que le type l’indique. (Spoiler : ce n’est pas toujours le cas.)

  1. Gênant avec les génériques

Quand votre composant utilise des types génériques, React.FC tend à rendre les choses plus compliquées, pas plus simples. La syntaxe devient lourde, et TypeScript est moins aidant, pas plus.

  1. Verbeux sans plus de clarté

Écrire const MyComponent: FC<Props> est plus long et généralement plus obscur que de typer simplement les props.

  1. Plus nécessaire

Les raisons initiales d’utiliser React.FC — support éditeur, inférence JSX — ont été largement couvertes par les améliorations de TypeScript. Ce qui était autrefois une astuce pratique est maintenant un style hérité.

Une Comparaison Côté à Côté

Caractéristique function Component() const Component: FC
Inclut children ? Seulement si déclaré Toujours inclus
Supporte les génériques ? Avec élégance Pas sans efforts
Verbeux ? Minimal Sensiblement plus
Support éditeur ? Suffisant Un peu mieux dans certains cas
Recommandé ? Oui Plus vraiment

L'Approche Recommandée

Le consensus dans la communauté est simple : typez directement vos props. Si vous voulez que votre composant accepte children, dites-le. Sinon, il ne les aura pas. C’est ce genre d’honnêteté que votre futur vous vous appréciera.

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

const MyComponent = ({ title, children }: Props) => (
  <div>
    <h1>{title}</h1>
    {children}
  </div>
);

C’est explicite. C’est maintenable. Et cela n’implique pas à tort que votre composant gère children quand ce n’est pas le cas.

Y a-t-il des Cas où FC a Encore du Sens ?

Parfois. Si vous travaillez sur une base de code legacy qui utilise beaucoup React.FC, la cohérence peut être plus importante que de tout réécrire. Si vous prototypez rapidement des composants sans vous soucier du typage de children, FC peut encore servir de raccourci.

Mais en général, ce sont les exceptions qui confirment la règle.

En Conclusion

React.FC n’est pas faux. Il n’est juste plus nécessaire. TypeScript moderne a rendu le typage des composants React plus simple et plus prévisible sans lui.

Alors, la prochaine fois que vous pensez à FC, faites une pause et demandez-vous si vous apportez de la valeur — ou juste des couches en plus. Le plus souvent, une fonction simple typée vous servira bien mieux.

En logiciel — comme dans la vie — la clarté l’emporte sur l’esprit malin. Et moins de surprises signifie généralement moins de regrets.

Categories