Dans cette dernière partie de la série de didacticiels sur les blocs personnalisés de Gutenberg, nous apprendrons à utiliser des composants d’ordre supérieur pour utiliser les composants de WordPress afin d’effectuer des requêtes pour les publications et d’autres informations de base sur WordPress.
Dans la partie précédente, nous avons découvert les blocs dynamiques et nous avons fini par implémenter une fonctionnalité permettant de saisir un ID de publication et d’utiliser PHP pour récupérer dynamiquement la publication et la rendre en mode frontend et aperçu. Saisir manuellement un identifiant de publication n’est ni intuitif ni convivial. Il est préférable de fournir à l’utilisateur un moyen de sélectionner ou de rechercher des publications par titre de publication et de cliquer sur quelque chose pour en choisir une.
Une partie de la résolution de ce problème est assez facile; comment interroger les publications à partir de la fonction de votre bloc edit. Nous avons quelques options pour cela, et la meilleure option consiste à utiliser certains des composants dits d’ordre supérieur de WordPress. Vous pouvez également utiliser les méthodes de navigateur Javascript pour effectuer un appel AJAX vers l’API WordPress REST en utilisant par exemple [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)ou axios. WordPress fournit en fait sa propre version de fetch: apiFetch().
L’autre partie de la résolution de cela dépend un peu de vous; qui est de savoir comment présenter la liste ou le choix dans notre bloc. Comment allez-vous présenter la liste des publications parmi lesquelles choisir ? Dans une sélection, une liste de cases à cocher ou de boutons radio ? Ou vous souhaitez offrir la possibilité de rechercher, et ainsi mettre en place une solution de saisie semi-automatique ou une solution de filtrage? Devriez-vous autoriser la sélection de plusieurs messages ou d’un seul ? Habituellement, vous pouvez résoudre ce problème en utilisant différents composants WordPress, mais vous devez décider quelle solution vous souhaitez mettre en œuvre.
Apprenons d’abord un peu les composants d’ordre supérieur et le module de données WordPress, avant de voir comment nous pouvons effectuer des requêtes de publication dans notre bloc.
Module WordPress Core Data et composants d’ordre supérieur
Lorsque vous travaillez avec React, vous devrez souvent transmettre l’état vers le bas aux composants enfants ou vers le haut à un composant parent commun afin que tous les autres composants enfants y aient accès. Une solution pour résoudre le problème de la centralisation de l’état d’une application consiste à utiliser Redux. Avec Redux, vous pouvez créer des magasins, qui sont des objets contenant l’état et les informations d’une application.
Le module WordPress Data est un hub de différents magasins et fournit des fonctions de gestion des données entre différents modules. Il est construit sur Redux – mais ne le confondez pas avec un Redux pour WordPress, car il existe de nombreuses différences. Vous pouvez enregistrer vos propres magasins dans WordPress, ou peut-être plus important encore, accéder aux magasins enregistrés de WordPress.
Voici un aperçu des magasins disponibles dans le module de données WordPress (cela changera probablement avec le temps). Toutes les boutiques WordPress sont contenues dans le module Core Data. Par exemple, il existe des magasins contenant les données de l’éditeur (core/editor), les avis (core/notices), les données de bloc (core/blocks), les informations sur la fenêtre d’affichage (core/viewport), et enfin et surtout le magasin principal lui-même – core.
Pour accéder aux données des magasins, vous devrez utiliser des sélecteurs. WordPress a un sélecteur dans le wp.datapackage ; [select](https://developer.wordpress.org/block-editor/packages/packages-data/#select)(). Vous pouvez également manipuler les magasins avec dispatch, mais cela n’est pas couvert par cette série de tutoriels. Vous pouvez en fait très facilement essayer le sélecteur vous-même pour voir ce qui est disponible dans les magasins WordPress.
Essayer le sélecteur
Ouvrez l’éditeur Gutenberg dans Chrome et ouvrez l’outil de débogage de la console. Tapez:
wp.data.select('core')Et appuyez sur Entrée. Vous devriez obtenir un objet en réponse avec tous les sélecteurs (fonctions) que vous pouvez utiliser. Comme exemples, vous trouverez des fonctions telles que getMedia, getTaxonomy, getAuthors, etc. Celui que nous utiliserons pour interroger les messages est également là mais n’a pas de nom intuitif ; ça s’appelle getEntityRecords. Pour le moment, certaines de ces fonctions sont documentées, mais la plupart ne le sont malheureusement pas.
Essayez également d’autres magasins que core, par exemple :
wp.data.select('core/editor').getBlocks()Cela renvoie toutes les informations sur tous les blocs actuellement dans votre message. Vous pouvez jouer avec cela dans le débogueur de la console Chrome et essayer d’appeler certaines fonctions pour voir ce que vous obtenez en réponse. Certains nécessitent des paramètres et d’autres non.
Pour utiliser les sélecteurs et accéder aux magasins, nous devons les utiliser dans des composants d’ordre supérieur. Les composants d’ordre supérieur sont simplement un modèle de faire quelque chose dans React. Nous passons un composant à une fonction (ou un composant) qui pourrait ajouter des accessoires, puis renvoyons un nouveau composant.
À l’intérieur du module WordPress Data, nous trouvons [withSelect](https://developer.wordpress.org/block-editor/packages/packages-data/#withSelect); un composant d’ordre supérieur qui peut être utilisé pour injecter des accessoires à l’aide de sélecteurs enregistrés. Autrement dit; à l’ intérieur withSelect, nous avons accès au sélecteur select()et pouvons l’utiliser pour effectuer des appels. Les résultats du sélecteur seront des accessoires du composant auquel nous passons withSelect. Si vous avez besoin de combiner plusieurs composants d’ordre supérieur, le module de données WordPress offre la composefonction, mais cela sort du cadre de ce didacticiel. Nous n’utiliserons qu’un seul composant d’ordre supérieur ; withSelect.
Cela a été beaucoup de théorie, alors commençons à regarder du code et des exemples pratiques.
Récupération des publications à l’aide de withSelect, select et getEntityRecords
Pour résumer ce qui précède, nous devons configurer le composant d’ordre supérieur withSelectpour notre bloc. À l’intérieur de celui-ci, nous pouvons utiliser des sélecteurs pour accéder aux magasins WordPress, qui seront des accessoires pour le composant que nous passons à withSelect. Nous utiliserons le coremagasin et le sélecteur getEntityRecordspour interroger les publications.
La fonction getEntityRecordsn’est malheureusement pas très documentée pour le moment. Mais j’ai appris que nous pouvons passer postTypecomme premier paramètre (type d’entité) puis le type de publication comme second paramètre (par exemple ‘ post‘ ou ‘ page‘). Le troisième paramètre est facultatif et peut être un objet avec des arguments de requête. Nous verrons le troisième paramètre plus tard.
Si vous avez suivi cette série de didacticiels de la partie précédente, vous auriez un bloc personnalisé qui accepte un ID de publication saisi manuellement dans une entrée de texte. Le bloc utilise PHP pour afficher dynamiquement la publication en frontend (et en mode aperçu). Supprimons l’obligation de saisir manuellement l’ID de publication et remplaçons-le par quelque chose de plus intuitif. Comme mentionné précédemment, vous devez décider vous-même comment présenter la liste des publications et la meilleure façon de laisser l’utilisateur choisir une publication. Pour rester simple, nous ajouterons une sélection de tous les titres de publication parmi lesquels choisir.
Codant lewithSelect
Commençons à coder cela. Nous devons d’abord déstructurer ce dont nous avons besoin du paquet de données ;
const { withSelect, select } = wp.data;Ensuite, nous utilisons la fonction withSelectde notre bloc editet transmettons notre composant d’édition ; FirstBlockEdit. À l’ intérieur, withSelectnous déstructurons selecten tant que paramètre et utilisons le sélecteur select()pour interroger les publications avec getEntityRecords. Nous renvoyons un objet avec une propriété que nous appelons et postsqui contient le résultat de l’ select()appel.
Avec le code au-dessus de notre composant, FirstBlockEdit, aura désormais un nouvel accessoire ; posts. Tout ce que nous renvoyons à l’intérieur du withSelectcomposant d’ordre supérieur sera accessible en tant qu’accessoires au composant que nous passons (dans la parenthèse à la toute fin).
Gestion des publications depuis le sélecteur
Nous pouvons maintenant entrer dans notre composant FirstBlockEditet jeter un œil au nouveau fichier props.posts. Étant donné que notre composant est un composant basé sur une classe, nous devons faire référence aux accessoires avec this. Déconnectons-nous de la console à l’intérieur de la render()fonction dansFirstBlockEdit :
render() {
const { attributes, setAttributes } = this.props;
console.log(this.props.posts);
...
}Gardez un œil sur le débogueur de votre console. Vous remarquerez peut-être que cela se connectera deux fois ; d’ abord null, puis quelque temps plus tard, il enregistre un tableau de messages. En effet, l’interrogation des publications se fait de manière asynchrone. Notre composant est d’abord rendu avant la réponse, moment auquel props.postsest null. Une fois que nous obtenons une réponse, notre composant est à nouveau rendu avec l’accessoire rempli. Vous devez toujours vous rappeler de tenir compte de ce petit laps de temps sans données dans votre code.
Ajout d’un select pour afficher les posts
Préparons-nous à remplir une sélection avec les articles renvoyés et pour cela, nous utiliserons le composant WordPress SelectControl. Le composant SelectControlaccepte un tableau de choix où chaque choix est un objet avec les propriétés valueet label.
Si vous jetez un coup d’œil à la (seconde) réponse enregistrée dans la console, vous pouvez voir que nous obtenons un tableau d’objets de publication. Chaque article contient la plupart des informations de l’article, mais pour les choix dans une sélection, nous ne sommes intéressés que par l’ID de l’article en tant que valeur et le titre de l’article en tant qu’étiquette. Nous allons donc parcourir la postsprop et remplir une variable de tableau que nous transmettrons à SelectControl. N’oubliez pas de gérer le petit laps de temps où se trouve l’ postsaccessoire null. Dans ce cas, nous remplirons le tableau de choix avec une option portant l’étiquette "Loading…".
Notez que nous devons faire référence au titre du message en tant que post.title.rendered. Vous pouvez regarder par vous-même dans la console connectée postset voir comment les informations sont structurées pour chaque publication.
Après cela, nous devons simplement ajouter un SelectControlpartout où nous le voulons. Il peut être à l’intérieur du bloc lui-même (de préférence dans le code pour le mode d’édition), ou à l’intérieur de l’inspecteur.
Nous définissons le SelectControlpour faire référence à l’attribut selectedPostIdque nous avons défini à l’étape précédente. Nous définissons la valeur enregistrée dans la prop valueet gérons sa mise à jour dans la onChangeprop – comme nous l’avons fait plusieurs fois auparavant. Nous nous assurons qu’un nombre est stocké en utilisant parseInt()parce que le selectedPostIda le type number. Et nous passons le tableau de choix généré dans la prop options.
C’est vraiment tout! Si vous avez suivi le code de l’étape précédente, vous devriez déjà avoir un code qui lit l’ID de publication enregistré et l’affiche !
Bien sûr, je vous recommande d’implémenter la liste et le choix des publications différemment d’une simple sélection. Ce n’est pas une solution jolie ou conviviale, en particulier pour les sites avec beaucoup de publications. En parlant de nombre de posts, avez-vous remarqué que le sélecteur getEntityRecords ne renvoie qu’un maximum des 10 derniers posts? C’est le comportement par défaut de getEntityRecords, mais nous pouvons modifier la requête post en passant un troisième paramètre.
Modifier la requête pour getEntityRecords
En passant un objet comme troisième paramètre à getEntityRecords, nous pouvons modifier la requête post. Comme mentionné précédemment, malheureusement, la documentation pour getEntityRecordsest manquante. Mais en lisant partout sur le Web, j’ai rassemblé une liste d’arguments de requête possibles;
per_page: définissez un nombre pour limiter le nombre de publications. Défini sur-1pour récupérer le maximum de 100. Par défaut10.exclude: Exclure certains articles de la requête. Définissez un ID de publication ou un tableau de nombres pour plusieurs ID de publication.parent_exclude: exclure certains messages parents. Défini sur un ID de publication ou sur un tableau de plusieurs ID de publication.orderby: Décidez de l’ordre des publications. Vous pouvez très probablement utiliser les mêmes paramètres que dans le orderby de WP_Query. Peut être par exemple ‘menu_order‘.order: Soit'asc'ou ‘desc'pour un ordre croissant ou décroissant.status: Filtrer par statut de publication. Il peut s’agir d’une chaîne, d’une chaîne avec plusieurs statuts séparés par une virgule ou d’un tableau de chaînes de statut. Par exemple['publish', 'draft'], pour interroger les messages publiés et rédigés.categories: filtrer les messages par certaines catégories. Fournissez un ID de catégorie ou un tableau d’ID de catégorie. Je pense que cela ne fonctionne que pour les catégories de publication et non pour les autres taxonomies personnalisées.tags: Filtrer les messages par certaines balises. Fournissez un ID de balise ou un tableau d’ID de balises. Fonctionne uniquement pour les balises de publication et non pour les autres taxonomies personnalisées.search: Ajoutez une requête de recherche (chaîne).
Remarque : Cette liste n’est pas exhaustive et est également susceptible d’être modifiée !
Modifions notre requête. Nous voulons faire deux choses; nous voulons d’abord récupérer tous les messages et pas seulement les 10 derniers. Pour ce faire, nous fournissons -1à per_page. Deuxièmement, nous voulons exclure la publication actuelle de la liste des publications en fournissant l’ID de publication actuelle à exclude. Cela n’a souvent aucun sens d’afficher un raccourci de publication ou un aperçu de la publication actuelle elle-même.
Tu pourrais penser; attends, comment obtient-on l’identifiant du poste actuel ? N’oubliez pas que nous, dans le composant d’ordre supérieur withSelectet avec le selectsélecteur, pouvons accéder à tous les magasins de données de base de WordPress. L’ID de publication actuel est une chose naturelle à stocker dans l’un des principaux magasins WordPress. À l’ intérieur core/editor, nous trouvons la fonction getCurrentPostId().
Modifions le withSelectretour à quelque chose comme ceci :
Le changement ci-dessus est assez explicite. Nous générons un objet de requête avec les propriétés per_pageet excludeet le transmettons comme troisième paramètre à getEntityRecords(). Maintenant, notre props.postsintérieur du FirstBlockEditcomposant doit répertorier tous les messages mais exclure le message actuel.
Conclusion
Cet article conclut la série de didacticiels Comment créer des blocs Gutenberg personnalisés. La série était destinée à passer en revue les bases du développement de vos propres blocs personnalisés, vous fournissant un point de départ pour développer vos propres blocs plus complexes. Gardez certainement un œil sur d’autres tutoriels liés à Gutenberg ici. Peut-être trouverez-vous un tutoriel expliquant plus spécifiquement quelque chose que vous vouliez faire vous-même !