Explorez comment Jordan Walke et React ont introduit des composants réutilisables, une UI déclarative et un rendu piloté par l'état — remodelant l'architecture frontend moderne.
Jordan Walke est un ingénieur logiciel surtout connu pour avoir créé React alors qu'il travaillait chez Facebook. Avant React, les frontends étaient souvent construits autour de pages, de templates et d'une pile croissante de « glue code » qui tentait de garder HTML, CSS et JavaScript synchronisés. L'idée clé de Walke a été d'inverser le modèle : au lieu de traiter l'UI comme un ensemble de documents que l'on modifie au fil du temps, considérez-la comme un arbre de petits composants réutilisables que l'on compose pour créer des fonctionnalités plus larges.
Ce n'était pas qu'une nouvelle bibliothèque — c'était une nouvelle façon de penser l'UI. Un composant regroupe un morceau d'interface avec la logique et l'état dont il a besoin, puis expose une interface claire (props) au reste de l'application. Cela rend la construction d'interfaces plus proche de l'assemblage de briques Lego que de l'édition d'une page fragile.
React a compté parce qu'il a aidé les équipes à :
Nous passerons en revue les idées pratiques qui ont rendu React influent :
Vous n'avez pas besoin d'être un expert en framework pour suivre. L'objectif est de clarifier le modèle mental — pour reconnaître de bons patterns React, éviter les idées reçues et appliquer ces principes même hors React.
Avant React, de nombreuses équipes construisaient des interfaces riches en assemblant des templates, des manipulations DOM à la jQuery et une pile croissante de règles « quand X arrive, mettre à jour Y ». Ça fonctionnait — jusqu'à ce que l'interface devienne complexe.
Un pattern courant était : récupérer des données, rendre du HTML, puis attacher des gestionnaires d'événements qui modifiaient le DOM directement. Dès que l'état changeait (un nouvel élément, une erreur de validation, un basculement), quelqu'un devait se souvenir de chaque endroit qui en dépendait.
Cela menait à des bugs tels que :
Au fur et à mesure de l'évolution des écrans, les mêmes règles métier se retrouvaient dupliquées dans plusieurs handlers : « désactiver le bouton si le champ est vide », « surligner les éléments non lus », « afficher l'état vide s'il n'y a pas de résultats ». Quand les exigences changeaient, il fallait fouiller dans des fichiers non liés pour mettre à jour chaque copie.
Les données peuvent être modélisées avec quelques structures claires : une liste d'articles, un objet utilisateur, un ensemble de filtres. L'UI, en revanche, ajoute des combinaisons : chargement vs chargé, erreur vs succès, lu vs non lu, édition vs lecture, filtré vs non filtré — souvent tout en même temps.
Imaginez un fil d'actualités :
Sans une règle prévisible comme « l'UI est une fonction de l'état », vous vous retrouvez à coordonner de nombreuses modifications du DOM qui peuvent entrer en conflit. L'objectif de React était de rendre les mises à jour fiables : changez les données/l'état, et l'UI se re‑rend à chaque fois pour correspondre.
Un composant est une petite partie de l'interface utilisateur que vous pouvez nommer, réutiliser et raisonner sur de manière isolée. En langage simple : un composant prend des entrées et renvoie ce à quoi l'UI doit ressembler pour ces entrées.
Ce cadrage « entrées → sortie » est le cœur du modèle de composant. Plutôt que de traiter un écran comme un grand template, vous le scindez en briques ayant un but — boutons, cartes, menus, formulaires, et sections entières — puis vous les assemblez.
Dans React, les entrées les plus courantes sont les props. Les props sont des valeurs que vous passez à un composant pour le configurer : texte, nombres, flags, gestionnaires d'événements, ou même d'autres UI.
La sortie est l'UI que le composant rend. Si les props changent, le composant peut produire une sortie différente — sans que vous deviez chercher manuellement où mettre à jour le DOM.
Par exemple, un composant Button pourrait recevoir des props comme label, disabled et onClick. Un UserCard pourrait recevoir name, avatarUrl et status. Vous pouvez lire l'interface d'un composant (ses props) comme un cahier des charges : « De quoi cette UI a‑t‑elle besoin pour s'afficher correctement ? »
Découper l'UI en composants rapporte vite :
Modal, Input ou Dropdown peut apparaître sur plusieurs pages.C'est un grand changement par rapport au copier‑coller et à l'ajustement de markup par page. Les composants rendent la duplication inutile — et à terme, inacceptable.
React vous encourage à concevoir l'UI comme un système composé de parties. Une « page de paiement » devient un arbre de composants — CheckoutPage contenant OrderSummary, ShippingForm et PaymentMethod. Chaque partie a des entrées claires et une responsabilité claire.
Ce changement — penser d'abord en composants — est une raison majeure pour laquelle React a transformé l'architecture frontend. Il a donné aux équipes une unité partagée de design et de développement : le composant.
Le plus grand changement mental de React est l'UI déclarative : vous décrivez à quoi l'interface doit ressembler pour un état donné, et React se charge de mettre à jour la page quand cet état change.
Au lieu de chercher manuellement des éléments, modifier du texte, basculer des classes et garder le DOM synchronisé, vous vous concentrez sur la « forme » de l'UI. Quand les données changent, l'UI est redécrite et React calcule l'ensemble minimal de modifications nécessaires.
JSX est un moyen pratique d'écrire la structure d'un composant avec une syntaxe qui ressemble au HTML à l'intérieur de JavaScript. Ce n'est pas un nouveau langage de template à apprendre depuis zéro ; c'est une abréviation pour « ce composant rend cet arbre d'éléments ».
L'avantage clé est que le markup et la logique qui décident quoi afficher vivent ensemble, ce qui rend les composants plus faciles à comprendre en isolation.
Le code impératif se concentre sur comment mettre à jour l'UI étape par étape :
// Imperative: manually keep the DOM in sync
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
Le code déclaratif se concentre sur ce que l'UI doit être pour l'état courant :
function Status({ isLoggedIn }) {
return (
\u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
\u003c/p\u003e
);
}
Parce que le rendu s'exprime comme une description pure, les composants ont tendance à être plus lisibles, plus faciles à relire et plus simples à refactoriser. Les designers, les ingénieurs orientés produit et les nouveaux venus peuvent souvent suivre le JSX sans fouiller dans des gestionnaires d'événements et des mutations DOM.
Cette clarté améliore la collaboration : les décisions d'UI sont visibles en un seul endroit, et les changements sont moins susceptibles de créer des effets secondaires cachés ailleurs.
L'« état » est simplement les données qui peuvent changer dans le temps pendant qu'un utilisateur interagit avec votre UI. Cela peut être le texte courant d'une recherche, si un menu est ouvert, les éléments d'un panier, ou le résultat d'une requête réseau. Si ça peut changer et que l'écran doit le refléter, c'est de l'état.
Le mouvement clé de React est de considérer le rendu comme la conséquence de l'état, pas comme une série d'étapes manuelles sur le DOM. Vous décrivez à quoi doit ressembler l'UI pour un état donné. Quand l'état se met à jour, React re‑rend les parties concernées.
Ce modèle mental diffère de « trouver un élément, puis mettre à jour son texte, puis basculer cette classe ». À la place, vous mettez à jour l'état, et l'UI s'actualise naturellement parce qu'elle est dérivée de cet état.
Le flux de données unidirectionnel signifie que les données circulent dans une seule direction :
Cela réduit les surprises car vous pouvez suivre le chemin d'une mise à jour : un événement se produit, l'état change en un seul lieu, et l'UI se re‑rend à partir de ce nouvel état. Il y a moins d'ambiguïté du type « qui a changé cette valeur ? ».
function Counter() {
const [count, setCount] = React.useState(0);
return (
\u003cdiv\u003e
\u003cp\u003eCount: {count}\u003c/p\u003e
\u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
\u003c/div\u003e
);
}
Ici, count est l'état. Cliquer sur le bouton met à jour l'état avec setCount. React re‑rend alors et le paragraphe affiche le nouveau nombre. Vous ne « modifiez » jamais directement le DOM.
Le même pattern s'applique pour filtrer des listes (état = texte du filtre, UI = éléments filtrés) ou la validation de formulaires (état = valeurs de champs et erreurs, UI = messages). Les données changent d'abord ; la vue n'en est que le résultat.
L'idée clé de React n'est pas « redessiner la page plus vite ». C'est : considérer l'UI comme le résultat de l'état, et quand l'état change, comparer ce que vous voulez maintenant avec ce que vous aviez avant — puis mettre à jour uniquement ce qui a réellement changé.
Quand l'état ou les props d'un composant changent, React appelle vos composants à nouveau pour produire une nouvelle description de l'UI. Imaginez deux instantanés :
Plutôt que de vider le DOM et de tout reconstruire, React cherche à calculer l'ensemble minimal d'opérations DOM nécessaire pour passer de A à B.
Le « DOM virtuel » est simplement la représentation en mémoire de l'UI de React — un arbre léger d'éléments (et de sorties de composants) qui décrit ce qui doit être à l'écran. Ce n'est pas un second navigateur ni un DOM plus rapide. C'est une structure de données que React peut inspecter et comparer efficacement.
La réconciliation est le processus qui consiste à déterminer ce qui a changé entre l'arbre virtuel précédent et le suivant. React utilise des heuristiques pour le faire rapidement, par exemple :
\u003cdiv\u003e n'est pas un \u003cspan\u003e)key) aident à identifier les éléments dans les listes afin que React puisse associer « le même élément » entre deux rendusUne fois que React sait ce qui a changé, il applique des mises à jour ciblées au DOM réel.
Ce n'est pas de la magie. Les performances dépendent des patterns : clés stables, éviter les re‑renders inutiles, garder le travail des composants léger et ne pas faire de calculs coûteux pendant le rendu. React peut réduire le churn DOM, mais votre structure de composants et votre flux de données déterminent encore la fluidité perçue de l'app.
Le meilleur atout de React pour monter en charge n'est pas une option ou un add‑on technique — c'est la composition : construire des écrans en imbriquant des composants, en passant des données via des props et en utilisant children pour qu'un composant « enveloppe » une autre UI.
Quand les équipes s'appuient sur la composition, elles arrêtent de penser en pages ponctuelles et commencent à penser en petites pièces fiables qu'on peut réarranger sans tout réécrire.
childrenL'imbrication reflète la structure visuelle de l'UI : une page contient des sections, qui contiennent des cartes, qui contiennent des boutons. Les props sont les molettes de configuration (texte, états, callbacks). Et children permet de créer des composants qui fournissent une structure tout en laissant l'appelant décider du contenu interne.
Un bon modèle mental : props personnalisent, children remplissent, l'imbrication assemble.
Composants de layout définissent la structure et l'espacement sans posséder la logique métier. Exemples : Page, SidebarLayout, Stack, Modal. Ils s'appuient souvent sur children pour que le même layout enveloppe plusieurs écrans.
Inputs réutilisables standardisent le comportement et le style des formulaires : TextField, Select, DatePicker. Au lieu de copier labels, états d'erreur et messages de validation à travers les écrans, vous centralisez ces décisions et exposez une API simple via les props.
Listes et composants d'item gardent l'UI répétée prévisible. Une séparation courante est ItemList (récupération, pagination, états vides) et ItemRow (comment un seul élément apparaît). Cela facilite la modification du rendu sans casser la gestion des données.
Les hooks sont le moyen moderne de réutiliser du comportement à état (bascules, état de formulaire, récupération) dans plusieurs composants sans les contraindre à la même forme UI. Cette séparation aide les équipes à faire évoluer le design tout en gardant la logique cohérente.
La composition est le mécanisme qui permet aux design systems de rester cohérents : les composants deviennent les briques « approuvées », et les layouts définissent les règles d'espacement et de hiérarchie. Quand le système évolue — couleurs, typographie, états d'interaction — les produits héritent des améliorations avec moins de modifications manuelles.
L'état n'est que « les données qui peuvent changer ». En React, l'endroit où cet état vit est aussi important que l'état lui‑même.
L'état local appartient à un seul composant (ou petit widget) et n'a pas besoin d'être lu ailleurs. Pensez : si un dropdown est ouvert, la valeur courante d'un input, ou quel onglet est sélectionné.
Garder cet état local réduit la coordination et rend les composants plus réutilisables. Règle pratique : si un seul composant s'en soucie, ne l'exportez pas au reste de l'app.
L'état partagé concerne des données que plusieurs parties de l'UI doivent voir de la même façon. Exemples courants :
Quand plusieurs composants ont besoin de la même source de vérité, dupliquer l'état crée des désaccords (« l'en‑tête dit 3 items, la page panier dit 2 »).
Remonter l'état : déplacer l'état vers le parent commun le plus proche et le passer via des props. C'est souvent l'option la plus simple et garde le flux de données explicite.
Context : utile lorsque de nombreux composants ont besoin d'une même valeur sans « prop drilling », comme le thème ou l'auth. Context est préférable pour des préoccupations larges et relativement stables.
Stores externes : quand l'état devient complexe (mises à jour fréquentes, données dérivées, workflows cross‑page), un store dédié peut centraliser la logique et les mises à jour.
Le flux unidirectionnel de React brille lorsqu'il existe un propriétaire clair pour chaque morceau d'état. Visez une source unique de vérité quand c'est pratique, et dérivez le reste (comptes, totaux, listes filtrées) au lieu de stocker des duplications.
Le plus grand gain quotidien de React n'est pas une astuce de rendu — ce sont les frontières de composants qui transforment le travail UI en changements plus petits et plus sûrs. Quand un composant a une responsabilité claire et une surface publique stable (ses props), les équipes peuvent refactorer l'intérieur sans imposer des réécritures à travers l'app. Cette stabilité facilite les revues de code, réduit les régressions accidentelles et aide les nouveaux venus à savoir où agir.
Un modèle mental utile : donné des props et un état, un composant doit décrire l'UI de façon prévisible. Même si des effets et des APIs navigateur existent, la plupart de la logique d'un composant peut rester déterministe. Voilà pourquoi les tests maintenables en React se concentrent souvent sur le comportement et la sortie :
Les vérifications d'accessibilité s'intègrent naturellement : si vous testez via les rôles et les noms accessibles, vous détectez tôt les labels manquants, les états de focus cassés et les sémantiques incohérentes. Les contrôles de cohérence (linting, formatage, usage du design system) renforcent la même idée : des composants prévisibles sont plus faciles à maintenir.
Quand les composants exposent une API de props petite et cachent les détails d'implémentation, plusieurs personnes peuvent travailler en parallèle — l'un ajuste le style, un autre change la récupération des données, un troisième met à jour les tests — sans se marcher dessus.
La performance React concerne moins « React est lent » que « combien de travail votre app demande au navigateur ». L'UI la plus rapide fait le moins : moins de nœuds DOM, moins de layout/reflow, moins de calculs coûteux et moins d'allers‑retours réseau.
Un problème fréquent est les re‑renders inutiles : un petit changement d'état provoque le re‑render d'un large sous‑arbre parce que l'état est placé trop haut, ou parce que des props changent d'identité à chaque rendu (nouveaux objets/fonctions créés inline).
Un autre point classique est les longues listes — des centaines ou milliers de lignes avec images, formatage et handlers. Même si chaque ligne est « bon marché », le travail total s'accumule et le défilement devient saccadé.
Commencez par la structure :
Concentrez‑vous aussi sur ce que ressent l'utilisateur : réduisez la latence des saisies, accélérez le first meaningful paint et gardez les interactions fluides. Une amélioration de 20 ms sur une interaction fréquente peut compter plus qu'économiser 200 ms sur un écran rarement utilisé.
L'état dérivé est une donnée que vous pouvez calculer à partir d'autres états/props (comme fullName à partir de firstName + lastName, ou des éléments filtrés à partir d'une liste + requête). Le stocker crée souvent des bugs : vous avez alors deux sources de vérité qui peuvent diverger.
Privilégiez le calcul des valeurs dérivées pendant le rendu (ou la mémoïzation si c'est coûteux). Stockez seulement ce que vous ne pouvez pas dériver — typiquement la saisie utilisateur, les réponses serveur et l'intention UI (par ex. « le panneau est ouvert ? »).
React n'a pas seulement introduit une meilleure façon d'écrire l'UI ; il a incité les équipes à réorganiser la manière dont les frontends sont construits, partagés et maintenus. Avant que le modèle par composants ne devienne la norme, beaucoup de projets traitaient l'UI comme des pages avec des scripts et templates dispersés. Avec React, l'unité d'architecture est de plus en plus le composant : une brique d'UI avec une API claire (props) et un comportement prévisible.
React s'est bien intégré à l'essor des single‑page applications (SPAs). Quand le rendu est piloté par l'état, la « page » cesse d'être un template servi par le serveur et devient une composition de composants plus un routage côté client. Ce changement a rendu courant le fait d'organiser le code autour de zones fonctionnelles et de composants réutilisables plutôt qu'autour de fichiers HTML séparés.
Une fois l'UI construite à partir de pièces réutilisables, il est naturel de standardiser ces pièces. Beaucoup d'organisations sont passées du copier‑coller de markup à la création de bibliothèques de composants : boutons, contrôles de formulaire, modaux, primitives de layout et patterns comme les états vides. Avec le temps, ces bibliothèques ont souvent évolué en design systems — composants partagés plus guidelines — pour permettre aux équipes d'expédier des expériences cohérentes sans réinventer l'UI à chaque écran.
Les composants ont encouragé les équipes à nommer les choses de la même façon. Quand tout le monde parle d'un \u003cButton\u003e, d'un \u003cTooltip\u003e ou d'un \u003cCheckoutSummary\u003e, les discussions deviennent plus concrètes : on peut débattre du comportement et des frontières, pas seulement du visuel. Ce vocabulaire partagé aide aussi les nouveaux arrivants à s'approprier le code plus vite car le système est découvrable depuis le code.
Le succès de React a influencé la manière dont la communauté frontend conçoit l'UI : développement component‑first, rendu déclaratif et flux de données prévisibles sont devenus des attentes communes. D'autres frameworks ont adopté des idées similaires, même si les détails d'implémentation diffèrent, parce que ces pratiques se sont avérées plus faciles à faire évoluer en équipe.
React a mérité sa réputation en facilitant l'évolution d'interfaces complexes, mais ce n'est pas gratuit. Connaître les compromis dès le départ aide les équipes à l'adopter pour les bonnes raisons — et à éviter les décisions par copie‑conforme.
React a une courbe d'apprentissage : composants, hooks et modèles mentaux comme les mises à jour d'état et les effets demandent du temps. Le React moderne suppose aussi un outillage de build (bundling, linting, TypeScript en option mais courant), ce qui ajoute de la configuration et de la maintenance. Enfin, React introduit des couches d'abstraction — bibliothèques de composants, routage, patterns de récupération de données — qui peuvent être utiles, mais qui cachent aussi la complexité jusqu'au moment où quelque chose casse.
« React n'est que la vue. » En théorie, oui ; en pratique, React influence fortement votre architecture. Les frontières de composants, la propriété de l'état et les patterns de composition façonnent le flux de données et l'organisation du code.
« Le DOM virtuel est toujours plus rapide. » Le DOM virtuel concerne surtout des mises à jour prévisibles et l'ergonomie pour les développeurs. React peut être rapide, mais les performances dépendent des patterns de rendu, de la mémoïzation, de la taille des listes et de l'évitement des re‑renders inutiles.
React est un excellent choix pour des applications avec beaucoup d'états interactifs, des bases de code durables et plusieurs développeurs travaillant en parallèle. Pour un site marketing essentiellement statique ou quelques widgets simples, des options plus légères (templates server‑side, JS minimal ou frameworks plus simples) peuvent être plus faciles à livrer et à maintenir.
Si vous prototypez une application React et voulez valider ces idées rapidement (frontières de composants, propriété d'état, patterns de composition), un workflow de prototypage assisté peut aider. Par exemple, Koder.ai vous permet de décrire des fonctionnalités en chat et de générer un frontend React fonctionnel plus un backend Go/PostgreSQL, puis d'itérer avec snapshots/rollback et d'exporter le code source quand vous êtes prêt à reprendre la main. C'est une façon pratique de tester des décisions d'architecture sur une vraie fonctionnalité avant de s'engager dans une construction complète.
Suivant : prototypez une fonctionnalité réelle, mesurez la complexité et la vélocité d'équipe, puis faites évoluer les patterns de manière délibérée — pas par défaut.
Jordan Walke a créé React alors qu'il travaillait chez Facebook. React a été important parce qu'il a remplacé le fragile « glue code » de manipulation manuelle du DOM par une approche basée sur des composants et un rendu piloté par l'état, ce qui rend les interfaces complexes plus faciles à faire évoluer, déboguer et maintenir.
Les templates ont tendance à répartir les règles d'interface entre le markup et des gestionnaires d'événements dispersés (« quand X arrive, mettre à jour Y »). Les composants encapsulent l'UI et la logique derrière une petite interface (props), ce qui permet de composer des fonctionnalités à partir de pièces prévisibles au lieu de patcher des pages au fil du temps.
Un composant est une unité réutilisable qui prend des entrées (généralement des props) et renvoie ce à quoi l'interface devrait ressembler pour ces entrées.
En pratique, visez :
Les props sont les entrées que vous passez à un composant pour le configurer (texte, flags, callbacks, ou autre UI). Considérez les props comme un contrat :
disabled, onSubmit) plutôt que des objets « kitchen sink » vaguesL'UI déclarative signifie que vous décrivez ce que l'interface doit être pour l'état courant, pas comment mettre à jour le DOM pas à pas.
En pratique :
JSX est une syntaxe qui vous permet d'écrire la structure de l'UI d'une manière ressemblant à du HTML à l'intérieur de JavaScript. C'est utile parce que la logique de rendu et le markup qu'elle contrôle coexistent, rendant un composant plus facile à lire et à relire comme une unité.
L'état (state) est toute donnée susceptible de changer au fil du temps et qui doit affecter ce que l'utilisateur voit (texte d'un champ, état de chargement, contenu du panier, etc.).
Règle pratique : stockez la source de vérité (saisie utilisateur, réponses serveur, intention UI) et dérivez tout le reste (comptes, listes filtrées) à partir de celle‑ci.
Le flux de données unidirectionnel signifie :
Cela facilite le débogage car on peut tracer la mise à jour dans une ligne droite : événement → changement d'état → re‑render.
Le DOM virtuel est la représentation en mémoire de l'UI que React utilise. Quand l'état/les props changent, React compare la description UI précédente avec la nouvelle et met à jour le DOM réel seulement là où c'est nécessaire.
Pour éviter les problèmes courants :
key stables pour les éléments de listesCommencez simple et élargissez quand nécessaire :
Privilégiez une source unique de vérité et dérivez le reste pour éviter les divergences.