Le cycle de vie n'existe pas dans React avec des hooks

Il y a très, très, très longtemps, nous utilisions React avec des classes, vous vous souvenez ?

A cette époque, nous avions le concept de méthodes de cycle de vie, des méthodes sur les classes qui acceptaient des rappels qui seraient exécutés à certains moments. Les trois grands : au montage, à la mise à jour et au démontage.

Des cours anciens mais dorés

C'était important, sur les composants de classes, le JSX renvoyé était créé selon la méthode de rendu, l'état attaché au this du composant, et le développeur de l'application avait besoin d'un moyen de savoir effectuer des actions à certains moments. Nous avons eu l'idée du temps sur la durée de vie d'un composant :

• composantDidMount est le moment où le composant s'affiche pour la première fois et ajoute des éléments au DOM et c'est le moment de démarrer la connexion et les effets secondaires tels que les requêtes API.
• ShouldComponentUpdate vous permet de définir manuellement votre logique pour comparer les accessoires et l'état suivants et de renvoyer un booléen pour définir si le nouveau rendu peut être ignoré ou non.
• composantDidUpdate est le moment où l'état ou les accessoires ont changé, appelant à nouveau la méthode de rendu et effectuant les modifications de réconciliation pour la différence d'identité et s'appliquant au DOM, bon pour synchroniser l'état avec les nouveaux accessoires et faire des choses logiques.
• ComponentWillUnmount était le moment où React supprimait les éléments du DOM et était un bon endroit pour nettoyer les choses et éviter les fuites de mémoire.

Et bien sûr, vous disposiez d'une API importante telle que forceUpdate, qui vous permettait de déclencher manuellement un re-rendu si vous utilisez des données externes qui ne se connecteraient pas aux mises à jour d'état de React.

Au niveau conceptuel, nous avons une manière plus directe de gérer le flux de l'application. Les méthodes de cycle de vie suivaient un cycle de vie similaire à celui d'un élément DOM, vous pouviez créer des mémo et forceUpdates par vous-même, la synchronisation de l'état était la manière par défaut de faire de la logique.

Cette franchise était considérée comme simple, et apprendre ces concepts était plus facile que le modèle réactif. Mais ensuite, les crochets sont arrivés et ont tout changé.

La réactivité sans nom

La transition était déroutante. Premièrement, dans le but de faciliter les choses et, en quelque sorte, de maintenir la vision conceptuelle du modèle React qu'avaient les développeurs, de nombreuses communications ont tenté de montrer les similitudes entre le modèle hooks. Pour avoir les 3 principales méthodes de cycles de vie, ils ont montré des solutions de contournement avec useEffect.

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);

Ainsi, la plupart du nouveau code React créé avec des hooks a suivi cette idée, et commencer à synchroniser l'état était un processus naturel. Afin de conserver la même idée des méthodes de cycle de vie, c'était le bon endroit pour appeler setState et déclencher le processus de re-rendu.

Quel est le problème ?

L'état de synchronisation est devenu un problème, la mauvaise utilisation de useEffect est devenue un problème, les doubles rendus sont devenus un problème, trop de nouveaux rendus sont devenus un problème, les performances sont devenues un problème.

C'est un peu déroutant cette étape de React, du moins pour moi. Parce que le passage aux crochets était un passage à un modèle réactif, même s’il s’agit d’un modèle à gros grains. Mais la communication était que rien de vraiment changé. Aucun contenu sur les concepts et la théorie de la réactivité, même en travaillant pendant des années avec React, j'ai juste commencé à vraiment comprendre la réactivité en lisant les articles de blog de Ryan Carniato sur la réactivité et la solidité.

Même en sachant que useEffect avait été utilisé à mauvais escient, je ne comprenais vraiment pas pourquoi, et ce manque de théorie conceptuelle sur la réactivité rend si facile la commission d'erreurs avec les hooks. useEffect est devenu le hook le plus détesté, étant appelé «useFootgun» pour certaines personnes. Le fait est qu'il existe une confusion conceptuelle dans React qui s'exprime dans tous les problèmes liés à useEffect que nous voyons aujourd'hui.

Les problèmes useEffect ne sont pas la cause du problème, mais la conséquence.

Qu'en est-il du cycle de vie avec des crochets

Alors, c'est ça le problème. Il n'y a pas de cycle de vie dans la notion de réactivité.

Vous avez un changement, vous y réagissez en provoquant et en provoquant des effets secondaires. Les effets sont la conséquence et non la cause. Il n'y a pas de synchronisation d'état et aucun concept de montage et de démontage.

Peu importe qu'il s'agisse du premier, du 10ème ou du dernier rendu avant le démontage, et les hooks s'en moquent, d'ailleurs, même useEffect.

Essayez-le :

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);

Vous verrez sur votre console les deux fonctions exécutées à chaque mise à jour d'état. D'abord celui du nettoyage, puis le rappel de l'effet. Si vous utilisez useEffect avec un état ou un accessoire pour effectuer un abonnement, chaque fois que les dépendances changent, la fonction de nettoyage sera appelée, puis le nouveau rappel, refaisant l'abonnement, mais avec les nouvelles valeurs.

Vous devriez regarder le code de votre application comme le modèle React simplifié :

function EffectExample() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect', count);

    return () => {
      console.log('clean up', count);
    }
  }, [count]);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

Si vous avez un composant comme celui-ci :

UI = fn(state)

ce que vous avez réellement, lorsque vous cliquez sur le bouton et ajoutez 1 au décompte, conceptuellement, c'est quelque chose comme ceci :

function Example() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

Chaque clic appelle à nouveau le fn, avec un nouvel état, générant une nouvelle version de l'UI. L'état doit changer par l'action de l'utilisateur ou par une valeur asynchrone qui doit être effectuée avec des dérivations asynchrones.

De cette façon, vous gardez l'idée propre :

• les transitions d'état effectuent un nouvel appel fn
• avec le nouvel état, vous obtenez la description de l'interface utilisateur
• si c'est différent, mettez à jour l'écran.

Un modèle épuré et cohérent.

c'est au moteur de rendu de s'occuper de l'ajout, de la mise à jour et de la suppression d'éléments de l'écran. Au niveau des composants, ce qui compte c'est :

• si l'état a changé
• si l'application peut gérer les actions de l'utilisateur
• la structure renvoyée dans le JSX.

Hooks et son modèle réactif permettent à React de se découpler du navigateur, ce qui fait que le code de l'application ne se soucie pas du moment où vous vous trouvez dans le processus de rendu d'écran. Vous ne forcez plus les mises à jour et ne gérez même plus les mémos selon vos propres règles, c'est moins direct pour le développeur de l'application, mais plus direct en termes de modèle.

Chaque re-rendu génère une structure, React s'occupe du reste.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!