Notre code a tendance à devenir de plus en plus lourd, nous allons donc le découper en plusieurs parties en créant des composants React. On va notamment placer le code de l’inspecteur et de la toolbar dans des fichiers séparés.
Sommaire du cours
Dans le cours précédent notre code dans edit.js commençait à devenir assez lourd. Le but de ce cours va être de scinder notre code en plusieurs fichiers.
Dans ce cours on va utiliser l’exemple 14 : src/14-components/ qui est simplement la reprise du bloc des exemples précédents, mais que j’ai scindé en plusieurs composants :
On a :
edit.jsqui va s’alléger et appeler les sous-composants ;toolbar.jsqui s’occupera seulement de la barre d’outils ;settings.jsqui s’occupera uniquement des réglages de notre inspecteur ;block.jsqui s’occupera du rendu du bloc dans l’éditeur.
Cette organisation est complètement arbitraire mais elle fait sens dans notre cas. Ce sera à vous d’opter pour la configuration idéale en fonction du contexte.
Les avantages à utiliser des sous-composants
Il y a plusieurs avantages à scinder son code en sous-composants. Le plus évident étant que votre code s’en retrouvera plus léger, et donc plus lisible.
Cela permet également de bien isoler les différents « pôles » de votre composant. Je pense en premier lieu à la Toolbar, l’inspecteur ainsi que le bloc : dans les exemples précédents tout était écrit à la suite, désormais chaque élément isolera son code dans son propre composant, lui-même dans son propre fichier JS.
De plus il faut savoir qu’un composant peut gérer sa propre logique (traitement des données) avant de les renvoyer au parent, ça évite d’ajouter trop de fonctions au composant principal.
Votre fichier edit.js, sera donc allégé en terme d’imports. Chaque composant importera les composants nécessaires à son fonctionnement depuis @wordpress/block-editor, @wordpress/components et autres.
Déclarer un composant
On va commencer par voir comment déclarer un composant React. Pour cela on va regarder src/13-composants/toolbar.js :
En premier lieu, on va devoir charger Component de @wordpress/element, c’est une fine surcouche Gutenberg du composant React basique.
Ensuite, il suffit de déclarer une classe avec le nom que l’on veut donner à notre composant, dans ce cas Toolbar.
Comme d’habitude on retrouve la fonction render() qui nous permettra d’afficher notre HTML.
On va pouvoir rajouter autant de fonctions que l’on veut avant le render(), et React propose même des hooks qui vont se lancer automatiquement lorsque le composant va se mettre à jour.
Pour rappel une des particularités de React est d’être capable de gérer le cycle de vie des composants et de mettre à jour automatiquement l’affichage de ceux dont les données ont changé.
Pensez à jeter également un oeil à settings.js et block.js pour voir comment est organisé le code à l’intérieur.
Écriture alternative
Il se peut que vous voyez dans d’autres exemples une écriture légèrement différente :
Dans ce cas l’export est écrit à la fin du code. C’est exactement la même chose donc peut importe l’écriture utilisée.
En fait je ne sais pas si vous vous en souvenez, mais on avait déjà fait un export pour notre pictogramme SVG personnalisé. On avait simplement exporté une constante au lieu d’une classe, mais sinon c’est le même principe !
D’ailleurs les développeurs de WordPress n’utilisent pas la classe pour gérer les composants, mais une simple fonction. C’est tout à fait suffisant au final :
Il n’y a pas de grande différence à notre niveau, j’ai choisi les classes mais c’est purement arbitraire. À vous de voir ce qui vous convient le mieux !
Appeler nos sous-composants React
Dans edit.js, il faut maintenant importer nos composants en début de fichier en utilisant l’instruction import. Pour cela on va indiquer le nom que l’on a donné à la classe (avec sa majuscule) suivi de from puis le nom de fichier dans lequel la trouver.
./ indique que l’on reste dans le dossier dans lequel on se trouve actuellement. Notez qu’il n’est pas nécessaire de mettre l’extension .js à la fin.
Et dans la fonction return() on peut désormais utiliser nos composants en les appelant comme une balise HTML :
Dans ce cas on a un bel allègement de notre code. On comprend tout de suite que l’on retourne notre Toolbar, nos réglages d’inspeceur et notre bloc !
Par contre, on va devoir transmettre nos props aux composants, afin qu’ils puissent à leur tour utiliser les valeurs et les fonctions. Je pense notamment à setAttributes().
Pour transmettre tout cela, il suffit de faire comme tout composant HTML natif, c’est-à-dire écrire des attributs dans notre composant, et ça ressemble à ceci :
Mais c’est très redondant puisque les clés et les valeurs sont tout le temps les mêmes. Du coup il existe avec React une écriture simplifiée qui commence avec les 3 petits points : <Toolbar { ...props } />.
En soi, ce que je viens d’écrire fonctionne tout le temps, mais c’est très bourrin : on envoie absolument toutes les props du composant parent vers l’enfant, même s’il n’en a pas l’utilité. En général ce n’est pas nécessaire pour des questions de performances.
Si vous envoyiez une valeur inutile dans ce composant, il serait mis à jour quand cette valeur change, alors qu’il n’en n’aurait pas le besoin. Du coup mieux vaut ne transmettre que le strict nécessaire.
D’ailleurs, par curiosité j’ai ajouté un console.log(props) dans mon bloc et voici ce que j’ai obtenu :
On a pas mal de données intéressantes. Mais seulement une poignée d’entre elles le sera réellement pour nos sous-composants.
On va donc lister seulement les valeurs et les fonctions à envoyer, avec ... devant, et React fera l’assignation clé/valeur lui-même.
Envoi des props utiles au composant
C’est le moment idéal pour utiliser l’écriture déstructurée que l’on a vu dans le précédent cours :
Dans ce cas précis je l’ai fait en 2 fois : j’ai d’abord déstructuré les props pour avoir les attributes au complet, puis j’ai ensuite déstructuré attributes pour avoir chaque valeur indépendamment.
- Dans la Toolbar j’envoie setAttributes et l’alignement seulement ;
- Dans l’inspecteur j’envoie chapterSign, textColor, withRadius, radius et également setAttributes ;
- Et dans le bloc j’envoie className, setAttributes, et tous les attributs d’un coup.
Concernant le bloc, on a en effet besoin de tous nos attributs, puisque en théorie on va tous les utiliser. On a également besoin du setAttributes car c’est dans le bloc que l’on édite directement number et title, via les RichText.
C’est pour ça que j’ai d’un côté extrait de props attributes, et ensuite j’en ai fait une version décomposée. J’aurais pu sinon tout décomposer d’un coup et envoyer toutes les valeurs en les listant, mais ça fait long et peu élégant.
Récupérer les props dans le sous-composant
On va maintenant s’attarder sur nos sous-composants. Tout ce que l’on récupère du parent (qui cette fois n’est pas Gutenberg, mais notre bloc) sont des props.
Je peux donc à nouveau faire un petit coup d’assignation destructurée :
Exceptionnellement pour le composant Block, comme j’ai transmis directement attributes, un objet composé de sous-objets, je dois le double déstructurer pour taper title au lieu de attributes.title.
Et du coup, maintenant que vous savez faire des composants, n’hésitez pas à organiser votre code en entités réutilisables. Vous pouvez même appeler des sous-sous-composants et créer autant de niveaux que nécessaire.
Il faut simplement à chaque fois passer les bonnes props et le tour est joué.
Avec la connaissance de l’assignation destructurée et la création de composants, vous êtes maintenant parés pour créer des blocs toujours plus complexes mais qui gardent heureusement un code clair et organisé.
Il est maintenant temps de vous mettre à l’épreuve avec un nouveau devoir, avant d’attaquer les blocs dynamiques.
0
Questions, réponses et commentaires