Un compteur de clics, un champ de formulaire en cours de saisie, un onglet actuellement sélectionné : ces valeurs qui changent au fil de l’interaction et doivent immédiatement se refléter à l’écran portent un nom précis dans les frameworks réactifs, l’état. Il se distingue des simples variables JavaScript classiques par une propriété essentielle : le modifier déclenche automatiquement un nouveau rendu du composant concerné.
L’état dans l’éditeur de blocs WordPress
Chaque bloc de l’éditeur gère son propre état via le hook React useState, ou pour des besoins plus larges partagés entre plusieurs composants, via le magasin de données de WordPress (@wordpress/data), une couche d’état global comparable à Redux. Un bloc qui affiche un panneau de réglages typique gère par exemple un état local pour savoir si le panneau est déplié, tandis que le contenu du bloc lui-même vit dans les attributes, une forme d’état persistée dans le contenu de l’article.
Exemple
const [ ouvert, setOuvert ] = wp.element.useState( false );
return wp.element.createElement( 'button', {
onClick: () => setOuvert( ! ouvert )
}, ouvert ? 'Fermer' : 'Ouvrir' );
Pièges fréquents
- Modifier directement une variable d’état sans passer par sa fonction de mise à jour (
setOuvertplutôt que réaffecterouvert) : le composant ne se rafraîchit alors pas, un bug classique et déroutant pour un débutant. - Multiplier les états locaux redondants qui devraient n’en former qu’un seul, ce qui complique la synchronisation et augmente le risque d’affichages incohérents entre eux.
- Confondre état et props : les props sont transmises par un composant parent et ne doivent jamais être modifiées directement, contrairement à l’état, propre au composant qui le détient.