All posts in React

La gestion des états dans React

React est une librairie JavaScript dédiée à la constructions d’ interfaces pour des applications web.
L’un des plus gros challenges dans une application React est d’afficher des données de manière efficace et efficiente. Plus l’application grandit, plus il devient difficile d’orchestrer correctement tous les composants tout en évitant les re-rendus inutiles.Nous allons voir, au cours de cet article, les différents moyens de partager de l’information entre les composants d’une application React. Nous verrons aussi les pièges à éviter pour faciliter la gestion des états dans React.

UseState et prop-drilling

Le flux de données dans React est unidirectionnel. Cela signifie que les données circulent dans un seul sens : des composants parents vers les composants enfants. L’objectif est de favoriser une architecture de données propre et prévisible.

Les props permettent de transmettre des données des composants parents aux composants enfants. Elles sont en lecture seule dans le composant enfant, ce qui garantit que ce dernier ne peut pas modifier directement ces données.

La gestion des états avec useState et prop-drilling

Le « prop-drilling » désigne le processus de transmission des props à travers plusieurs couches de composants. Certains de ces composants n’utilisent pas directement ces données et ne font que les relayer à leurs propres composants enfants.

La gestions des états dans React et l'enfer du prop-drilling

Cela peut entraîner des difficultés de débogage, des comportements inattendus, ainsi que des composants étroitement couplés et difficiles à réutiliser.

React Context

Les contextes React permettent à un composant parent de mettre certaines informations à disposition de n’importe quel composant de l’arborescence, quelle que soit sa profondeur. La donnée devient ainsi accessible sans avoir à la transmettre explicitement via des props, ce qui permet de résoudre le problème du prop-drilling.

Un composant « abonné » à un contexte (via le hook useContext) est automatiquement re-rendu lorsqu’une modification intervient dans ce dernier. Cependant, toute modification d’une partie du contexte entraîne le re-rendu de tous les composants abonnés.

La gestions des états dans React avec les contextes

On peut alors envisager de créer un contexte par type de donnée afin de les partager dans notre arbre de composants. Mais que se passe-t-il si l’on se retrouve avec 50 contextes différents ? On plonge alors dans l’enfer des contextes.

La gestions des états dans React et l'enfer des contextes

L’enfer des contextes React survient lorsque l’API Context est utilisée de manière excessive ou inappropriée. C’est comme si votre application devenait un puzzle à trop de couches, rendant l’ensemble difficile à suivre et à maintenir.

Imaginez une situation avec de nombreuses couches, chacune contenant des éléments différents, comme des états ou des fonctions. Cela devient un véritable fouillis, difficile à comprendre, à tester et à maintenir.

Stores Redux

Un store Redux est un emplacement qui contient toutes les données. A l’inverse des contextes React, nous n’avons besoin que d’un seul store, lequel peut être découpé en « slices » (morceaux). La modification d’une partie du store entraîne des re-rendus des composants abonnés à cette partie seulement.

Une mise à jour d’une partie du store est déclenchée depuis n’importe quelle partie de l’arbre des composants. Une action utilisateur est le plus souvent à l’origine du déclenchement. Dans la terminologie Redux, cela s’appelle « dispatch » d’actions.

La gestions des états dans React avec Redux

L’action est envoyée aux « reducers ». Ce sont des fonctions pures qui permettent de modifier l’état. Par exemple, une action « increment » déclenchera la fonction qui incrémente un compteur. Une autre action « addOrder » déclenchera la fonction qui ajoute une commande dans notre liste de commandes, etc.

La fonction reducer est exécutée, puis la partie du store concernée est mise à jour. Finalement, les composants abonnées déclenchent un re-rendu.

Conclusion

Nous avons vu au cours de cet article différentes façons de maintenir des données pour optimiser la gestions des états dans React. Ils est possible de combiner ces trois concepts précédemment étudiés, mais il est nécessaire de savoir quand et comment les utiliser :

  • Utilisez le prop-drilling lorsque vous souhaitez passer des données à des dumb-components. Ceux-ci se contenteront d’afficher les données passées en paramètres, sans les transmettre à nouveau à d’autres composants.
  • Utilisez les contextes pour des données de haut niveau qui nécessitent un re-rendu global : gestion du thème, de la langue, des préférences utilisateur, de l’authentification, etc.
  • Utilisez un store Redux pour gérer les données métier : liste d’utilisateurs, liste de factures, etc.

Vos composants React sont-ils purs ?

Quand on développe des applications web avec React, il faut s’assurer que les composants se comportent de manière prévisible et performante. L’un des concepts clés pour y parvenir est celui des composants purs. Que signifie « composant pur », et pourquoi cela est si important ? Avec cet article, nous allons expliquer ce concept, comparer des exemples de composants purs et non purs, et finalement s’intéresser aux tests unitaires qui garantissent la pureté des composants.

Qu’est-ce qu’un composant pur ?

composants React purs

Un composant pur est un composant qui génère toujours le même résultat pour des entrées et un état donné. Le rendu d’un composant dépend seulement de ses entrées et est totalement déterminé par celles-ci. Si les entrées et l’état ne changent pas, le composant rendra toujours le même résultat, peu importe le nombre d’appels.

Les composants purs sont plus faciles à tester, plus performants et ont moins d’effets secondaires indésirables. Avec React, il est possible de créer un composant pur en utilisant la classe React.PureComponent ou en écrivant un composant fonctionnel qui n’introduit pas d’effets secondaires.

Composants non purs

Un composant non pur peut avoir des effets secondaires ou un comportement qui dépend de facteurs autres que ses entrées et son état.: Il peut s’agir par exemple de variables globales, d’états internes non contrôlés, ou d’appels à des API qui modifient le rendu de manière imprévisible. Ces composants sont difficiles voir impossible à tester et à debuguer, car leur sortie ne dépend pas toujours de leurs entrées et état.

Voici un exemple simple de composant non pur :

import React from 'react';

export default function VisitCounter({ count }) {
  
  if (count <= 10 ) {
    document.getElementById('counter').className = 'red';
  } else {
    document.getElementById('counter').className = 'green';
  }

  return (
    

Number of visits: {count}

); }

Dans cet exemple, le changement de la classe introduit un effet secondaire qui peut rendre le comportement du composant imprévisible, ce qui complique les tests.

Composants purs : exemple

import React from 'react';

export default function VisitCounter({ count }) {
 
  let className;

  if (count <= 10) {
    className = 'red';
  } else {
    className = 'green';
  }

  return (
    

Number of visits: {count}

); } export default React.memo(VisitCounter);

Ici, le composant VisitCounter dépend de l’entrée « count » et l’affiche dans une balise « h1 ». On utilise React.memo pour optimiser ce composant et éviter des re-rendus inutiles si la propriété en entrée ne change pas.

Pourquoi utiliser des composants purs ?

Utiliser des composants purs présente plusieurs avantages :

  • Prévisibilité : un composant pur est facile à comprendre et à tester. Son comportement ne dépend pas d’effets secondaires ou de dépendances externes.
  • Optimisation des performances : React peut optimiser le rendu des composants purs en évitant les re-rendus inutiles grâce à la comparaison des propriétés en entrée. Il faut utiliser React.PureComponent ou React.memo.
  • Facilité des tests unitaires : tester des composants purs est plus simple, car leur sortie dépend uniquement de leurs entrées. Cela permet de rédiger des tests plus ciblés et fiables.

Exemple de test unitaire

Voici un exemple de test unitaire pour vérifier le comportement des composants purs.

Tester un composant pur comme VisitCounter est simple. Vérifions que l’entrée est bien rendue dans le retour du composant.

import React from 'react';
import { render, screen } from '@testing-library/react';
import { VisitCounter } from './VisitCounter';

describe(' test', () => {
  test('renders correctly', () => {
    render();
    expect(screen.getByText('Number of visits: 0')).toBeInTheDocument();
    const counter = screen.getByTestId('counter'); 
    expect(counter).toHaveClass('red');
  });
});

Conclusion

Les composants purs offrent de nombreux avantages, qui sont principalement la prévisibilité et la performance. En évitant les effets secondaires, nous créons des composants plus robustes, plus simples et plus faciles à tester. En suivant les bonnes pratiques et en utilisant les classes et méthodes adaptées (React.memo ou React.PureComponent), nous améliorons la qualité de notre code React et améliorons l’expérience utilisateur.

Et vous, vos composants React sont-ils purs ?