{"componentChunkName":"component---src-templates-blog-post-js","path":"/fr/making-setinterval-declarative-with-react-hooks/","result":{"data":{"site":{"siteMetadata":{"title":"Ibrahim personal blog","author":"Ibrahim"}},"markdownRemark":{"id":"c5f0b315-8a9b-52f4-a1af-9b7b01ad8d2b","html":"

Si vous avez joué avec les Hooks React pendant plus de quelques heures, vous avez probablement buté sur un curieux problème : utiliser setInterval ne marche juste pas comme on s’y attendrait.

\n

Pour reprendre les mots de Ryan Florence :

\n
\n

J’ai entendu pas mal de monde dire que quand on regarde setInterval avec les hooks, on se dit que sur ce coup React doit se sentir morveux…

\n
\n

Honnêtement, je trouve que ces personnes n’ont pas tort. C’est en effet déconcertant au premier abord.

\n

Mais j’ai aussi fini par y voir non pas un défaut des Hooks, mais un décalage entre le modèle de programmation de React et setInterval. Les Hooks, qui sont plus en phase avec le modèle de programmation de React que les classes, rendent ce décalage plus évident.

\n

Il y a une manière de les faire fonctionner ensemble sans souci mais elle n’est guère intuitive.

\n

Dans cet article, nous examinerons comment faire collaborer efficacement les intervalles et les Hooks, pourquoi cette solution est pertinente, et quelles nouvelles possibilités elle nous offre.

\n
\n

Avertissement : cet article se concentre sur un cas pathologique. Même si l’API simplifie une centaine de cas d’utilisation, les gens parleront toujours du cas qui est devenu plus difficile.

\n

Si vous ne connaissez pas les Hooks, ou ne comprenez pas pourquoi toute cette agitation, jetez plutôt un œil à cette introduction et à la documentation. Cet article suppose que vous avez bossé avec les Hooks pendant plus d’une heure.

\n
\n

Fais-moi voir le code

\n

Sans plus attendre, voici un compteur qui s’incrémente à chaque seconde :

\n
import React, { useState, useEffect, useRef } from 'react';\n\nfunction Counter() {\n  let [count, setCount] = useState(0);\n\n  useInterval(() => {    // Votre logique métier ici    setCount(count + 1);  }, 1000);\n  return <h1>{count}</h1>;\n}
\n

(Et voici une démo sur CodeSandbox.)

\n

Ce useInterval n’est pas un Hook fourni par React ; c’est un Hook personnalisé que j’ai écrit :

\n
import React, { useState, useEffect, useRef } from 'react';\n\nfunction useInterval(callback, delay) {\n  const savedCallback = useRef();\n\n  // Se souvenir de la dernière fonction de rappel.\n  useEffect(() => {\n    savedCallback.current = callback;\n  });\n\n  // Configurer l’intervalle.\n  useEffect(() => {\n    function tick() {\n      savedCallback.current();\n    }\n    if (delay !== null) {\n      let id = setInterval(tick, delay);\n      return () => clearInterval(id);\n    }\n  }, [delay]);\n}
\n

(Et revoici la sous-préfète la démo CodeSandbox au cas où vous l’auriez loupée plus haut.)

\n

Mon Hook useInterval met en place un intervalle et le détruit après le démontage (le retrait du DOM virtuel, NdT). C’est une combo de setInterval et clearInterval associée au cycle de vie du composant.

\n

Sentez-vous libres de copier-coller ça dans vos projets ou d’en faire un module npm.

\n

Si vous vous fichez de savoir pourquoi ça fonctionne, vous pouvez cesser votre lecture ici ! Le reste de cet article est pour celles et ceux qui sont prêt·e·s à explorer les Hooks React plus en profondeur.

\n
\n

Keskispass ?! 🤔

\n

Je sais ce que vous vous dites :

\n
\n

Dan, ce code n’a aucun sens. Qu’est-il donc arrivé à « juste du JavaScript » ? Admets-le, React est parti en vrille avec les Hooks !

\n
\n

Je pensais pareil mais j’ai changé d’avis, et je vais changer le vôtre. Avant d’expliquer pourquoi ce code est pertinent, je veux la ramener un peu en vous montrant ce dont il est capable.

\n
\n

Pourquoi useInterval() est une meilleure API

\n

À titre de rappel, mon Hook useInterval accepte une fonction et une durée :

\n
  useInterval(() => {\n    // ...\n  }, 1000);
\n

Ça ressemble beaucoup à setInterval :

\n
  setInterval(() => {\n    // ...\n  }, 1000);
\n

Alors pourquoi ne pas utiliser directement setInterval ?

\n

Ce n’est sans doute pas évident au premier abord, mais la différence entre le setInterval que vous connaissez et mon Hook useInterval c’est que ses arguments sont « dynamiques ».

\n

Permettez-moi d’illustrer ça avec un exemple concret.

\n
\n

Disons qu’on veut que la durée de l’intervalle soit ajustable :

\n

\"Un

\n

Même si vous ne contrôleriez pas nécessairement la durée avec un champ, l’ajuster dynamiquement peut être utile—par exemple, pour ralentir le rythme de requêtes Ajax de mise à jour périodique lorsque l’utilisateur est passé sur un autre onglet.

\n

Alors comment feriez-vous ça avec un setInterval dans une classe ? Moi, je me suis retrouvé avec le code suivant :

\n
class Counter extends React.Component {\n  state = {\n    count: 0,\n    delay: 1000,\n  };\n\n  componentDidMount() {    this.interval = setInterval(this.tick, this.state.delay);  }  componentDidUpdate(prevProps, prevState) {    if (prevState.delay !== this.state.delay) {      clearInterval(this.interval);      this.interval = setInterval(this.tick, this.state.delay);    }  }  componentWillUnmount() {    clearInterval(this.interval);  }  tick = () => {    this.setState({      count: this.state.count + 1    });  }\n  handleDelayChange = (e) => {\n    this.setState({ delay: Number(e.target.value) });\n  }\n\n  render() {\n    return (\n      <>\n        <h1>{this.state.count}</h1>\n        <input value={this.state.delay} onChange={this.handleDelayChange} />\n      </>\n    );\n  }\n}
\n

(Et voilà la démo sur CodeSandbox.)

\n

C’est pas si mal !

\n

Et à quoi ressemble la version basée Hook ?

\n

🥁🥁🥁

\n
function Counter() {\n  let [count, setCount] = useState(0);\n  let [delay, setDelay] = useState(1000);\n\n  useInterval(() => {    // Votre logique métier ici    setCount(count + 1);  }, delay);\n  function handleDelayChange(e) {\n    setDelay(Number(e.target.value));\n  }\n\n  return (\n    <>\n      <h1>{count}</h1>\n      <input value={delay} onChange={handleDelayChange} />\n    </>\n  );\n}
\n

(Et sa démo sur CodeSandbox.)

\n

Et ouais, c’est tout.

\n

Contrairement à la version basée classe, il n’y a pas de montée en complexité afin « d’améliorer » notre exemple de Hook pour disposer d’une durée ajustable dynamiquement :

\n
  // Durée constante\n  useInterval(() => {\n    setCount(count + 1);\n  }, 1000);\n  // Durée ajustable\n  useInterval(() => {\n    setCount(count + 1);\n  }, delay);
\n

Quand le Hook useInterval voit une durée différente, il reconfigure l’intervalle.

\n

Au lieu d’écrire du code qui crée et efface l’intervalle, je peux déclarer un intervalle avec une durée particulière—et notre Hook useInterval s’occupe du reste.

\n

Et si je voulais mettre temporairement mon intervalle en pause ? Je peux le faire avec un état :

\n
  const [delay, setDelay] = useState(1000);\n  const [isRunning, setIsRunning] = useState(true);\n\n  useInterval(() => {\n    setCount(count + 1);\n  }, isRunning ? delay : null);
\n

(Voici la démo !)

\n

C’est le genre de truc sur les Hooks qui me redonne la pêche en React. On peut enrober des APIs impératives existantes et créer des APIs déclaratives qui expriment plus lisiblement notre intention. Tout comme avec le rendu, nous pouvons décrire le process dans toute sa temporalité simultanément plutôt que d’émettre précautionneusement toute une série de commandes pour le manipuler.

\n
\n

J’espère que ça vous a convaincus que le Hook useInterval() est une plus chouette API—au moins quand on s’en sert au sein d’un composant.

\n

Mais pourquoi est-il pénible d’utiliser setInterval() et clearInterval() avec les Hooks ? Revenons sur notre exemple de compteur pour tenter de l’implémenter à la main.

\n
\n

Première tentative

\n

Je vais commencer avec un exemple simple qui fait juste le rendu de l’état initial :

\n
function Counter() {\n  const [count, setCount] = useState(0);\n  return <h1>{count}</h1>;\n}
\n

Ensuite, je veux un intervalle qui l’incrémente à chaque seconde. C’est un effet de bord qui devra se nettoyer alors je vais utiliser useEffect() et renvoyer la fonction de nettoyage :

\n
function Counter() {\n  let [count, setCount] = useState(0);\n\n  useEffect(() => {    let id = setInterval(() => {      setCount(count + 1);    }, 1000);    return () => clearInterval(id);  });\n  return <h1>{count}</h1>;\n}
\n

(Voir la démo sur CodeSandbox.)

\n

Ça semble assez simple ? Ça marche pas trop mal.

\n

Pourtant, ce code a un comportement étrange.

\n

Par défaut, React ré-applique les effets à chaque rendu. C’est volontaire car ça permet d’éviter toute une catégorie de bugs qu’on trouve dans les composants React à base de classes.

\n

Ce comportement est généralement souhaitable car de nombreuses APIs d’inscription peuvent facilement retirer l’ancien écouteur et ajouter le nouveau à tout moment. Hélas, setInterval n’est pas de celles-ci. Quand nous appelons clearInterval et setInterval, leur planification se décale. Si nous refaisons un rendu et ré-appliquons les effets trop souvent, l’intervalle n’aura jamais l’opportunité de se déclencher !

\n

On peut voir ce bug en refaisant un rendu de notre composant au sein d’un intervalle plus court :

\n
setInterval(() => {\n  // Refait le rendu et ré-applique les effets de Counter,\n  // ce qui entraîne un clearInterval() et un setInterval()\n  // avant même que l’intervalle ne se déclenche.\n  ReactDOM.render(<Counter />, rootElement);\n}, 100);
\n

(Voir une démo de ce bug.)

\n
\n

Deuxième tentative

\n

Vous savez peut-être que useEffect() nous permet de refuser que nos effets soient ré-appliqués. On peut préciser un tableau de dépendances comme second argument, et React ne ré-exécutera notre effet que si quelque chose change dans ce tableau :

\n
useEffect(() => {\n  document.title = `Vous avez cliqué ${count} fois`;\n}, [count]);
\n

Quand nous voulons exécuter un effet seulement au montage, et le nettoyer au démontage, on peut passer un tableau de dépendances vides [].

\n

Cependant, c’est souvent la cause d’erreurs si vous n’êtes pas bien à l’aise avec les fermetures lexicales (closures, NdT) en JavaScript. Nous allons faire cette erreur dès maintenant ! (Notez qu’on est en train de construire une règle de linter conçue pour mettre en évidence ce type de bugs le plus tôt possible, mais elle n’est pas encore tout à fait prête.)

\n

Avec notre première tentative, notre problème venait du fait que la ré-exécution des effets effaçait trop tôt notre timer. On peut tenter de corriger ça en ne les ré-exécutant jamais :

\n
function Counter() {\n  let [count, setCount] = useState(0);\n\n  useEffect(() => {\n    let id = setInterval(() => {\n      setCount(count + 1);\n    }, 1000);\n    return () => clearInterval(id);\n  }, []);\n  return <h1>{count}</h1>;\n}
\n

Sauf que voilà, maintenant notre compteur monte à 1 et ne bouge plus. (Voir le bug en action.)

\n

Que s’est-il passé ?

\n

Le problème, c’est que useEffect capture la valeur de count issue du premier rendu. Il est égal à 0. On ne ré-applique jamais l’effet, alors la fermeture lexicale de setInterval référence toujours le count du premier rendu, et count + 1 est toujours 1. Oups !

\n

J’entends vos dents grincer d’ici. Les hooks sont énervants, pas vrai ?

\n

Une des manières de corriger ça serait de remplacer setCount(count + 1) par sa forme « fonction de mise à jour » setCount(c => c + 1). Elle pourra ainsi toujours lire l’état à jour dans cette variable. Mais ça ne nous aiderait pas à lire des props à jour, par exemple.

\n

Un autre correctif consisterait à utiliser useReducer(). Cette approche nous donne une meilleure flexibilité. Au sein du réducteur, vous avez accès tant à l’état courant qu’aux props à jour. La fonction dispatch elle-même ne change jamais, alors on peut y balancer des données depuis n’importe quelle fermeture lexicale. useReducer() est toutefois limité en ce qu’il ne permet pas d’émettre des effets de bord. (Ceci dit, vous pouvez renvoyer un nouvel état—qui pourrait déclencher un effet.)

\n

Mais pourquoi ça devient si compliqué ?

\n
\n

Le décalage d’impédance

\n

On emploie parfois ce terme, et Phil Haack l’explique ainsi :

\n
\n

On pourrait dire que les Bases de données viennent de Mars et les Objets de Vénus. Les bases de données n’ont pas de correspondance naturelle aux modèles objets. Ça revient en fait à essayer de faire coller les pôles Nord de deux aimants.

\n
\n

Notre « décalage d’impédance » n’est pas ici entre les Bases de Données et les Objets. Il survient entre le modèle de programmation de React et l’API impérative setInterval.

\n

Un composant React peut être monté pendant un bout de temps et passer par de nombreux états distincts, mais son résultat de rendu est censé tous les décrire d’un coup.

\n
  // Décrit tous les rendus possibles\n  return <h1>{count}</h1>
\n

Les Hooks nous permettent d’appliquer la même approche déclarative pour les effets :

\n
  // Décrit tous les états d’intervalle\n  useInterval(() => {\n    setCount(count + 1);\n  }, isRunning ? delay : null);
\n

On ne configure pas l’intervalle, mais on définit si il est actif, et avec quelle durée. Notre Hook s’occupe de la réalisation. Un processus continu est ici décrit en termes discrets.

\n

À l’inverse, setInterval ne décrit pas un processus dans le temps—une fois l’intervalle configuré, vous ne pouvez rien y changer, à part l’annuler.

\n

Voilà le décalage entre le modèle de React et l’API setInterval.

\n
\n

Les props et l’état des composants React peuvent changer. React refera leur rendu et « oubliera » tout du résultat du rendu précédent. Ce dernier n’a plus d’intérêt.

\n

Le Hook useEffect() « oublie » le rendu précédent, lui aussi. Il nettoie l’effet précédent et configure l’effet suivant. Cet effet suivant porte dans sa fermeture lexicale les props et l’état à jour. C’est pourquoi notre première tentative marche pour les cas simples.

\n

Mais setInterval « n’oublie » rien. Il référencera pour toujours les anciennes valeurs des props et de l’état, à moins que vous ne le remplaciez—ce que vous ne pouvez pas faire sans réinitialiser la planification.

\n

À moins que…?

\n
\n

Les refs à la rescousse !

\n\n

Le problème se résume à ceci :

\n\n

Alors si on ne remplaçait pas du tout l’intervalle, mais qu’on introduisait plutôt une variable modifiable savedCallback qui pointerait vers la fonction de rappel la plus récente pour l’intervalle ?

\n

On entrevoit maintenant la solution :

\n\n

Ce savedCallback modifiable doit pouvoir « persister » d’un rendu à l’autre. Il ne peut donc pas s’agir d’une variable classique. On veut quelque chose qui se comporte plus comme un champ d’instance.

\n

Comme on peut le voir dans la FAQ des Hooks, useRef() nous fournit exactement ça :

\n
  const savedCallback = useRef();\n  // { current: null }
\n

(Vous connaissez peut-être les refs DOM de React. Les Hooks utilisent le même concept pour garder sous la main des valeurs modifiables. Une ref est comme une « boîte » dans laquelle vous pouvez mettre ce qui vous chante.)

\n

useRef() renvoie un objet brut avec une propriété modifiable current, partagée d’un rendu à l’autre. On peut y sauvegarder la fonction de rappel la plus récente pour l’intervalle :

\n
  function callback() {\n    // Ici on a accès aux props et à l’état à jour, etc.\n    setCount(count + 1);\n  }\n\n  // Après chaque rendu, on sauve la fonction de rappel\n  // à jour dans notre ref.\n  useEffect(() => {    savedCallback.current = callback;\n  });
\n

Après quoi on peut la lire et l’appeler au sein de notre intervalle :

\n
  useEffect(() => {\n    function tick() {\n      savedCallback.current();    }\n\n    let id = setInterval(tick, 1000);\n    return () => clearInterval(id);\n  }, []);
\n

Grâce au [], notre effet n’est jamais ré-exécuté, du coup l’intervalle n’est pas réinitialisé. Néanmoins, grâce à la ref savedCallback, nous pouvons toujours lire la fonction de rappel définie lors du dernier rendu, et l’appeler à chaque tic de l’intervalle.

\n

Voici la solution complète qui fonctionne :

\n
function Counter() {\n  const [count, setCount] = useState(0);\n  const savedCallback = useRef();\n\n  function callback() {\n    setCount(count + 1);\n  }\n\n  useEffect(() => {\n    savedCallback.current = callback;  });\n\n  useEffect(() => {\n    function tick() {\n      savedCallback.current();    }\n\n    let id = setInterval(tick, 1000);\n    return () => clearInterval(id);\n  }, []);\n\n  return <h1>{count}</h1>;\n}
\n

(Voir la démo sur CodeSandbox.)

\n
\n

Extraire un Hook

\n

J’avoue, le code ci-dessus peut être déroutant. Ça tord un peu le cerveau de mélanger des paradigmes opposés. Il existe aussi un risque de mettre le bazar avec les refs modifiables.

\n

Je trouve que les Hooks fournissent des primitives de plus bas niveau que les classes—mais leur beauté réside en ce qu’ils nous permettent de les composer pour créer de meilleures abstractions déclaratives.

\n

Idéalement, j’aimerais juste pouvoir écrire :

\n
function Counter() {\n  const [count, setCount] = useState(0);\n\n  useInterval(() => {    setCount(count + 1);  }, 1000);\n  return <h1>{count}</h1>;\n}
\n

Je vais copier-coller le corps de mon mécanisme de refs dans un Hook personnalisé :

\n
function useInterval(callback) {\n  const savedCallback = useRef();\n\n  useEffect(() => {\n    savedCallback.current = callback;\n  });\n\n  useEffect(() => {\n    function tick() {\n      savedCallback.current();\n    }\n\n    let id = setInterval(tick, 1000);\n    return () => clearInterval(id);\n  }, []);\n}
\n

Pour le moment, ma durée de 1000 est codée en dur. J’aimerais en faire un argument :

\n
function useInterval(callback, delay) {
\n

Je vais l’utiliser pour configurer l’intervalle :

\n
    let id = setInterval(tick, delay);
\n

À présent que le delay peut changer d’un rendu à l’autre, j’ai besoin de le déclarer dans les dépendances de mon effet d’intervalle :

\n
  useEffect(() => {\n    function tick() {\n      savedCallback.current();\n    }\n\n    let id = setInterval(tick, delay);\n    return () => clearInterval(id);\n  }, [delay]);
\n

Attendez une minute, on ne voulait pas justement éviter de réinitialiser l’effet d’intervalle, en lui passant expressément [] pour cette raison ? Pas exacte­ment. On voulait juste éviter de le réinitialiser quand la fonction de rappel changeait. Mais si delay change, on veut redémarrer le timer !

\n

Voyons si notre code fonctionne :

\n
function Counter() {\n  const [count, setCount] = useState(0);\n\n  useInterval(() => {\n    setCount(count + 1);\n  }, 1000);\n\n  return <h1>{count}</h1>;\n}\n\nfunction useInterval(callback, delay) {\n  const savedCallback = useRef();\n\n  useEffect(() => {\n    savedCallback.current = callback;\n  });\n\n  useEffect(() => {\n    function tick() {\n      savedCallback.current();\n    }\n\n    let id = setInterval(tick, delay);\n    return () => clearInterval(id);\n  }, [delay]);\n}
\n

(Essayez donc sur CodeSandbox.)

\n

Ça marche ! On peut maintenant faire un useInterval() dans n’importe quel composant sans avoir à trop penser aux détails de son implémentation.

\n

Bonus : mettre l’intervalle en pause

\n

Disons que nous voulons pouvoir mettre l’intervalle en pause en passant null comme delay :

\n
  const [delay, setDelay] = useState(1000);\n  const [isRunning, setIsRunning] = useState(true);\n\n  useInterval(() => {\n    setCount(count + 1);\n  }, isRunning ? delay : null);
\n

Comment implémenter ça ? La réponse est simple : en ne configurant pas l’intervalle.

\n
  useEffect(() => {\n    function tick() {\n      savedCallback.current();\n    }\n\n    if (delay !== null) {      let id = setInterval(tick, delay);\n      return () => clearInterval(id);\n    }\n  }, [delay]);
\n

(Voir la démo sur CodeSandbox.)

\n

Et c’est tout. Ce code gère toutes les transitions possibles : changement de durée, pause, reprise de l’intervalle. L’API useEffect() nous demande de consacrer un plus gros effort en amont à la description de la mise en place et du nettoyage—mais rajouter des cas devient facile.

\n

Bonus : une démo rigolote

\n

Ce Hook useInterval() est vraiment marrant à utiliser. Quand les effets de bord sont déclaratifs, il est beaucoup plus facile d’orchestrer plusieurs comportements complexes.

\n

Par exemple, on peut faire que le delay d’un intervalle soit contrôlé par un autre :

\n

\"Compteur

\n
function Counter() {\n  const [delay, setDelay] = useState(1000);\n  const [count, setCount] = useState(0);\n\n  // Incrémenter le compteur.\n  useInterval(() => {\n    setCount(count + 1);\n  }, delay);\n\n  // Accélérer à chaque seconde !  useInterval(() => {    if (delay > 10) {      setDelay(delay / 2);    }  }, 1000);\n  function handleReset() {\n    setDelay(1000);\n  }\n\n  return (\n    <>\n      <h1>Compteur : {count}</h1>\n      <h4>Durée : {delay}</h4>\n      <button onClick={handleReset}>\n        Réinitialiser la durée\n      </button>\n    </>\n  );\n}
\n

(Voir la démo sur CodeSandbox !)

\n

En conclusion

\n

Les Hooks nécessitent de la pratique—en particulier à la frontière entre des codes impératif et déclaratif. Vous pouvez créer de puissantes abstractions déclaratives grâces à eux, comme React Spring, mais ils peuvent clairement parfois vous porter sur les nerfs.

\n

Nous n’en sommes qu’au début des Hooks, et nous avons clairement encore du boulot pour affiner et comparer les solutions et les bonnes pratiques. Ne précipitez pas votre adoption des Hooks si vous avez plutôt l’habitude de suivre des bonnes pratiques bien établies. Il nous reste beaucoup de choses à essayer et à découvrir.

\n

J’espère que cet article vous aura aidés à comprendre les pièges classiques associés à l’utilisation d’APIs telles que setInterval() avec les Hooks, à discerner les approches qui peuvent vous aider à vous en dépêtrer, et à goûter le fruit délicieux de la création d’APIs déclaratives plus expressives grâce à eux.

","timeToRead":18,"frontmatter":{"title":"Rendre setInterval déclaratif avec les Hooks React","date":"February 04, 2019","spoiler":"Comment j’ai appris à ne plus m’inquiéter et adorer les refs.","tags":null},"fields":{"slug":"/fr/making-setinterval-declarative-with-react-hooks/","langKey":"fr"}}},"pageContext":{"slug":"/fr/making-setinterval-declarative-with-react-hooks/","translations":["fr","zh-hans"],"translatedLinks":[]}}}