React Paris 2025 : De l'importance des utilisateurs (et des développeurs)

Marmelab a pu assister aux deux jours de conférence de la conférence React Paris 2025. Deux jours où nous avons été nourris de conseils, de méthodes, d'outils, presque tous autour des deux mêmes thèmes :

• prendre soin des utilisateurs (l'accessibilité, l'expérience utilisateur),
• prendre soin des développeurs (l'assistance de L'AI, les frameworks qui simplifient l'expérience développeur).

React est un excellent prétexte, mais ce qui se cache derrière ces sujets, c'est comment faire des produits agréables et utilisables, et comment les faire efficacement.

Voici nos retours sur les conférences, par ordre de préférence.

1. Démystifier l'accessibilité dans les applications React - Kateryna Porshnieva
2. React Server Components: Elevating Speed, Interactivity, and UX - Aurora Scharff
3. Utiliser efficacement l'IA en 2025 - Tejas Kumar
4. Abracadabra: The Vanishing Network - Kent C. Dodds
5. Goodbye, useState - David Khourshid
6. Type-Safe URL State Management in React with nuqs - François Best
7. Work Smarter, not Harder with Chrome DevTools - Dominika Zając
8. Let’s build K.I.T.T. with JavaScript - Nico Martin

L'accessibilité n'est pas triviale, et pourtant elle est nécessaire

Dans un talk magistral intitulé Démystifier l'accessibilité dans les applications React et extrêmement bien illustré, Kateryna Porshnieva nous a démontré à quel point l'accessibilité sur le web est un sujet important, d'une part, et absolument pas trivial, d'autre part.

Avant d'assister à ce talk je pensais bêtement que pour s'assurer qu'une application web est accessible, il fallait bien utiliser la sémantique HTML, mettre des aria-label, et s'assurer que les contrastes de couleurs soient suffisants.

J'avais raison, il faut penser à faire ça. Mais j'avais tort, c'est loin d'être suffisant.

Et ça peut même être pire si ce n'est pas fait avec rigueur. Selon les statistiques de Kateryna, il y a 34% d'erreurs d'accessibilité en plus sur des pages qui implémentent les attributs ARIA (Accessibility Rich Internet Application) que sur les pages qui ne les utilisent pas. Tout simplement parce que lorsque vous implémentez ARIA, vous faites la promesse aux navigateurs et divers outils pour malvoyants qu'ils vont pouvoir s'appuyer dessus pour interpréter vos pages. Si vous ne le faites pas, ces outils interprèteront la page avec le minimum vital disponible. Mais si vous le faites mal, ces outils vont saturer l'utilisateur de mauvaises informations et d'anomalies.

Cette présentation remplie d'exemples illustrés à la fois à l'écran et avec un screenreader convaincra n'importe quel développeur de prendre ce sujet au sérieux.

En voici quelques exemples :

• Utiliser aria-hidden={true} pour ignorer les icônes décoratives des boutons.
• Préférer les <label> avec htmlFor="inputId" plutôt que des labels encadrant l'input.
• Utiliser aria-describedby pour les inputs helpers.
• Utiliser l'onglet accessibilité sur Chrome pour explorer l'accessibility tree.

S'il ne doit y avoir qu'une conclusion à retenir, c'est cette réponse à la question d'un participant :

Comment faire accepter à son responsable d'avoir à passer du temps supplémentaire pour rendre son site accessible ?

• Ne demandez pas, faites-le !

L'accessibilité ne devrait pas être une option, mais faire partie de toute conception au même titre que la gestion d'erreur ou la sécurité.

Améliorer l'interactivité et l'expérience utilisateur

Plusieurs talks ont traité du sujet des React Server Components (RSC), notamment celui d'Aurora Scharff, React Server Components: Elevating Speed, Interactivity, and User Experience. Dans une présentation claire, mêlée d'une partie live-coding, elle nous a démontré comment les RSC et Suspense peuvent améliorer radicalement l'expérience utilisateur en réduisant le temps de réponse et en optimisant le rendu des différents éléments de la page.

La présentation didactique d'Aurora nous a provoqué une petite épiphanie. Pour un développeur React traditionnel, les RSC apportent un niveau d'indirection et de complexité supplémentaire. Pourquoi et comment déplacer un composant du client au serveur ? En fait, il faut avoir la réflexion inverse : concevoir une application multi-page app rendue côté serveur a priori, puis déporter des composants côté client pour améliorer l'expérience utilisateur.

Parmi les "outils magiques" de React 19 en mesure de faire changer la perception d'une page, notons :

• use()

  Permet d'utiliser une ressource en tant que promesse. Le composant est suspendu tant que la promesse est en pending, ou passe en fallback dans une utilisation wrappée dans <Suspence>

  function MessageComponent({ messagePromise }) {
    const message = use(messagePromise);
    const theme = use(ThemeContext);
    // Render something

• useTransition()

  Permet de traiter une action en tâche de fond sans bloquer les interactions avec l'utilisateur.

  function CheckoutForm() {
    const [isPending, startTransition] = useTransition();
    const [quantity, setQuantity] = useState(1);
  
    function onSubmit(newQuantity) {
      startTransition(async function () {
        const savedQuantity = await updateQuantity(newQuantity);
        startTransition(() => {
          setQuantity(savedQuantity);
        });
      });
    }
  }

• useOptimistic()

  Permet de mettre à jour un composant avant même que la tâche de fond liée ne soit résolue.

  const [optimisticMessages, addOptimisticMessage] = useOptimistic(
      messages,
      (state, newMessage) => [
        {
          text: newMessage,
          sending: true
        },
        ...state,
      ]
  );

• cache()

  Permet de mettre en cache un résultat lors du premier appel.

  const getMetrics = cache(calculateMetrics);
  
  function Chart({data}) {
    const report = getMetrics(data);
    // Render something
  }

On retiendra par ailleurs quelques bonnes pratiques :

• Résoudre les promesses le plus haut possible dans l'arborescence de composants (et afficher des squelettes en fallback pour tout composant qui attend un résultat).
• Afficher des indicateurs de chargement.
• Eviter les useEffect.
• Avoir le state dans l'URL, pour permettre de recharger la page ou de la partager (pour cela, nuqs est le candidat recommandé, nous en parlons plus bas dans cet article).
• Améliorer la page progressivement, par petites touches successives.

Pour ceux qui ont encore des doutes sur l'utilité des RSC, cette présentation est un must see. La dextérité d'Aurora en live-coding est à elle seule un spectacle qui vaut le détour.

Une IA qui streame l'interface utilisateur au client

Toujours dans l'idée de rendre l'interaction de l'utilisateur plus fluide, Tejas Kumar nous à, quant à lui, embarqué dans une séance de live-coding collaboratif dans sa présentation Utiliser efficacement l'IA en 2025. Sur un cas d'utilisation classique de chatbot basé sur OpenAI, l'objectif consistait à supprimer le temps d'attente entre la requête (l'envoi du prompt à l'IA) et la réponse (l'affichage du résultat). Le tout à grand renfort de vibe coding.

La solution une fois énoncée peut paraître simple :

• Utiliser un stream pour garder la connexion active avec l'API d'OpenAI
• Comme l'IA écrit sa réponse petit à petit, parser le contenu lu au fur et à mesure
• Et enfin, afficher le contenu parsé

Encore faut-t-il la mettre en œuvre correctement, en utilisant principalement trois astuces techniques :

• le format nd-json pour parser un JSON incomplet,
• un objet Buffer,
• et streamObject.

Le résultat est bluffant : la page affiche instantanément la réponse à peine la question envoyée, puis se complète progressivement.

Tejas est un orateur chevronné doublé d'un entertainer. Sa présentation vaut vraiment le coup ! Et le sentiment de satisfaction de l'assistance est d'autant plus grand qu'on a l'impression d'avoir codé tous ensemble.

Ne plus se soucier du code de la gestion du réseau

Dans une autre session de live-coding très dynamique, Kent C. Dodds nous a embraqué dans un tour de magie : faire disparaitre tout le code "technique" servant à gérer les échanges réseau de l'application pour ne garder que le pur fonctionnel. Sa conférence, intitulée Abracadabra: The Vanishing Network, est, comme toujours avec ce conférencier hors pair, un délice.

Spoiler alert : C'est grâce aux React Server Components (RSC)

Il part d'une tâche simple : combien de temps cela prend pour rajouter une checkbox à un formulaire ? On est tous tentés de répondre : Moins de 10 minutes. Mais dans un système complexe, il faut penser à toutes les couches qui vont être impactées et c'est toujours bien plus long que prévu.

Par améliorations successives, il nous a alors amené d'une application multi-page contenant des lignes et des lignes de code pour gérer les échanges de données, à une SPA, et finalement à une application dite "Modern React" utilisant RSC, où quasiment tout ce code avait finalement disparu.

La conclusion évidente est que les RSC simplifient énormément les développements web et la vie des développeurs au passage. Ils permettent de gagner beaucoup de temps en intégrant des mécanismes qu'il fallait avant coder intégralement pour chaque nouveau projet.

Il a terminé par ce conseil qu'on approuve largement :

Evitez de séparer les équipes frontend et backend. Ils devraient travailler comme une même équipe.

(A Marmelab, on va même plus loin, les développeurs frontend et backend sont les mêmes personnes ;) )

Simplifier et améliorer la gestion d'états

Deux orateurs nous ont parlé de useState, et plus précisément de comment l'éviter, pour améliorer une application en limitant, notamment, les re-rendus.

D'abord David Khourshid qui nous a présenté dans Goodbye, useState, à travers une série d'exemples bien choisis, les risques de useState et les alternatives.

Ce sont des conseils qu'on applique régulièrement et en voici un résumé :

• Ne pas utiliser de useState pour des données internes au composant qui ne sont pas partagées. Il est possible par exemple d'utiliser useRef à cet effet.

• Ne pas utiliser useState pour gérer des données de formulaire. FormaData est déjà lui-même un objet gérant un state. Et des outils très bien conçus comme Tanstack Query fournissent un gestionnaire d'état fiable et performant.

• Penser à regrouper les données dans un seul useState lorsque c'est possible, sous un objet unique.

• Et enfin, utiliser plutôt l'URL comme gestionnaire d'état, via useSearchParam

Et justement, pour masteriser ce concept d'URL as a state, François Best nous a présenté dans Type-Safe URL State Management in React with nuqs la puissance de nuqs, un gestionnaire d'état qui utilise l'URL, qu'il a conçu, et qui fait maintenant parler de lui.

Les arguments en faveur de nuqs sont amenés avec talent :

• Il permet la téléportation.

  Une page peut être partagée dans son état actuel à un tiers, en partageant uniquement son URL.

• Il permet le voyage dans le temps.

  L'historique de navigation permet de revenir aux états précédents d'une page facilement

• Et plus posément, il permet de recharger une page sans perdre d'information.

Il y a des limites à ce système, car une URL ne peut pas dépasser 2000 caractères environ. Et il peut également y avoir un vrai soucis de confiance.

En effet, si on vous partage l'URL https://marmelab.com/?lang=fr&status=7&userId=uivycvub84489dgv&time=2165489498, vous serez bien plus méfiant que si le lien est simplement https://marmelab.com/.

Pour ces deux cas, nuqs a trouvé une parade : le shortcutMapping. Il est facile de définir des raccourcis permettant de rendre l'URL plus digeste et moins longue.

Par ailleurs, nuqs offre un énorme avantage : il est type-safe. Toutes les données définies sont typées via l'utilisation de parsers.

En pratique, l'usage n'est pas beaucoup plus verbeux qu'un useState:

const [hello, setHello] = useQueryState("hello", { defaultValue: "" });
const [count, setCount] = useQueryState("count", parseAsInteger.withDefault(0),);

Assurément, nuqs sera un des prochains outils à tester pour nous.

Bien exploiter les devtools

Parler des Chrome Devtools est un marronnier dans les conférences sur le développement web. Mais ça n'empêche pas d'y trouver régulièrement des informations et des astuces très utiles. Et c'est exactement ce que nous a fourni Dominika Zając dans sa conférence Work Smarter, not Harder with Chrome DevTools, assez amusante et décalée.

D'excellents outils méconnus existent notamment pour vérifier l'accessibilité.

Comment avoir un résumé du look and feel d'un site, vérifier les contrastes ? La solution est dans Chrome Devtools -> More Tools -> CSS Overview -> Generate a report

Comment savoir si le site est suffisamment accessible ? La solution est dans Chrome Devtools -> More Tools -> Rendering -> Emulate [Something] Il suffit de choisir ensuite la situation à tester, mauvaise vision, daltonisme, ...

Comment indiquer a un utilisateur la marche à suivre sur une page, un formulaire ? La solution est dans Chrome Devtools -> More Tools -> Recorder Et il suffit d'exporter le "record"

La conclusion de ce talk :

Don't buy a tool, maybe it's in the browser !

Le sujet improbable avant de conclure

Parmi toutes ces excellentes conférences, il y a eu un OVNI : Celle de Nico Martin intitulée Let’s build K.I.T.T. with JavaScript.

Ce développeur freelance a ni plus ni moins réalisé l'exploit de construire KITT, la voiture parlante de la série télévisée K2000. (en miniature)

Avis aux nostalgiques des années 90.

Conclusion

Ce salon React Paris aura donc été l'occasion, non seulement de suivre l'évolution de la communauté React, mais également de voir à quel point cet outil, bien utilisé, permet de produire des applications utiles, pratiques, belles et permet de le faire avec un minimum d'effort.

D'autres frameworks majeurs existent qui répondent aussi à ces exigences, mais une chose est certaine, React et sa communauté ont parfaitement su s'adapter aux dernières pratiques et attentes du web et ils ont encore une longue vie devant eux.

N'hésitez pas à aller visionner ou revisionner les talks sur la playlist YouTube de la conférence, et à découvrir toutes celles dont n'où avons pas eu l'occasion de parler ici.

Rendez-vous au prochain salon React ;)