DE{CODE} : Gutenberg et WordPress sans tête

Gutenberg, alias WordPress blocks, offre aux producteurs de contenu de nouvelles façons puissantes de disposer le contenu dans un site WordPress traditionnel. Mais comment les développeurs WordPress sans tête peuvent-ils doter les équipes marketing de ces mêmes capacités ? Dans cette session DE{CODE}, le fondateur de GraphQL pour WordPress (WPGraphQL), Jason Bahl, partage de nouvelles fonctionnalités et les meilleures pratiques pour utiliser l'éditeur de blocs WordPress sur un site sans tête.

Diapositives de la session

Transcription du texte intégral

JASON BAHL : Salut. Bienvenue dans mon exposé sur Gutenberg et Headless WordPress. Je m'appelle Jason Bahl. Je suis le créateur et le mainteneur de WPGraphQL. Je suis ingénieur logiciel principal chez WP Engine. Vous pouvez me trouver sur Twitter @jasonbahl ou aussi sur Twitter @wpgraphql.

Alors aujourd'hui, je veux vous parler de ce qu'est même Gutenberg, de WordPress sans tête, quand et pourquoi vous voudrez peut-être utiliser WordPress sans tête, comment vous pouvez utiliser Gutenberg, en particulier, avec WordPress sans tête, et quand et pourquoi WordPress sans tête et Gutenberg ensemble pourrait avoir du sens pour vos projets.

Ainsi, WordPress a historiquement eu un éditeur qui ressemblait un peu à ceci. Nous avons eu une zone de texte TinyMCE, où nous pouvons modifier notre contenu. Nous pouvons insérer des médias, puis publier notre contenu, puis en 2018 est venu Gutenberg, cet éditeur basé sur des blocs, qui nous permet d'insérer du contenu dans cette toile vierge et d'interagir avec notre contenu au niveau du bloc.

Ainsi, chaque paragraphe a des paramètres. Chaque image a des paramètres. Chaque galerie, titre - tout ce à quoi vous pouvez penser pour le contenu est ce qu'on appelle le bloc. Et nous pouvons devenir vraiment précis avec la façon dont nous contrôlons notre contenu maintenant et nous pouvons le faire glisser et le déposer et composer notre contenu. C'est donc cette expérience d'édition très riche dans WordPress maintenant et c'est donc une introduction à ce qu'est Gutenberg.

Alors, qu'est-ce que Headless WordPress maintenant ? Alors pour comprendre Headless, regardons le WordPress traditionnel. Donc WordPress traditionnel, nous nous connectons à WordPress, l'interface utilisateur d'administration, et nous publions notre contenu, puis les utilisateurs visitent notre site, et PHP, le langage intégré à WordPress, rend la page. Il charge donc CSS, HTML et JavaScript et livre la page à l'utilisateur. C'est donc une sorte de WordPress traditionnel.

Avec Headless WordPress, vous utilisez toujours WordPress comme CMS. Vous publiez toujours du contenu, organisez du contenu, administrez du contenu dans WordPress, mais au lieu de fournir une page en HTML au navigateur, WordPress fournit des données généralement au format JSON, puis les applications clientes peuvent consommer ces données afin que nous puissions avoir des applications iOS ou Android natives. ou encore des applications de réalité virtuelle.

Mon collègue, Anthony, a partagé du contenu sur la façon dont il utilise WordPress pour alimenter les applications de réalité virtuelle. Ou j'ai travaillé dans un journal où nous utilisions WordPress comme point d'entrée pour nos journaux imprimés. Donc, si vous lisiez une copie papier d'un journal imprimé, vous lisiez du contenu produit dans WordPress.

Et bien sûr, nous pouvons toujours utiliser ces données pour le rendu sur le Web également, mais au lieu d'être verrouillés sur les modèles PHP, nous avons la possibilité de choisir la technologie frontale que nous voulons. Headless dissocie donc le back-end, la gestion du contenu et la manière dont nous présentons les données gérées dans WordPress.

Il existe donc deux façons courantes d'utiliser ces données. Nous pouvons obtenir des données au format JSON à partir de l'API WP REST, qui est une API intégrée à WordPress et il existe une autre API appelée WPGraphQL. Il s'agit d'un plugin open source que vous pouvez installer et extraire des données de WordPress et JSON. Et nous parlerons de WPGraphQL aujourd'hui.

Alors maintenant que nous savons ce qu'est WordPress, pourquoi pourriez-vous créer des projets WordPress sans tête ? Comme je l'ai mentionné, vous avez beaucoup de flexibilité dans le choix de votre technologie frontale. Et pour certaines personnes, c'est une chose très importante de pouvoir choisir comment ils construisent les projets front-end. Il existe des frameworks comme Next et Gatsby et Svelte qui ciblent vraiment les éléments vitaux Web de base améliorés. Ainsi, vous pourrez peut-être utiliser Headless avec WordPress et avoir amélioré les éléments vitaux Web de base.

Vous pouvez bénéficier de choses comme le fractionnement de code dans votre code. Vous pouvez ainsi créer des composants pour votre application frontale. Et en fonction du composant en cours de construction pour la page spécifique, vous enverrez moins ou moins d'actifs au client et accélérerez vos pages. Headless donne également aux développeurs un contrôle plus précis sur l'expérience utilisateur frontale, de sorte que les plugins installés dans l'administrateur WordPress ont moins d'impact sur le front-end.

Ainsi, les utilisateurs administrateurs ne peuvent pas simplement installer des plugins et ajouter des scripts arbitraires ou un balisage arbitraire au front-end d'un site Headless. C'est plus un développeur qui définit les contraintes sur le front-end et WordPress reçoit les données envoyées, puis l'une des choses que je veux saisir est l'expérience du développeur.

Avec Headless WordPress, puisque vous avez la possibilité d'utiliser la pile technologique de votre choix, vous bénéficiez dans certains cas d'une meilleure expérience de développement. Et l'un de ces cas que je vais aborder s'appelle le développement basé sur les composants et nous en parlerons beaucoup dans une seconde.

Voilà donc quelques raisons. Alors, dans quelles situations pourriez-vous vous trouver lorsque vous souhaitez utiliser Headless WordPress ? Eh bien, si vous avez besoin de créer des applications non Web comme le mobile natif, vous voudrez probablement passer à Headless. Encore une fois, si vos éléments vitaux Web de base sont médiocres sur votre site WordPress, votre site WordPress actuel, ou s'ils sont corrects, mais qu'il devient très coûteux de les maintenir en bon état, vous voudrez peut-être envisager Headless.

Si vous avez plusieurs applications dans votre organisation qui ont besoin d'extraire des données de WordPress, vous devrez peut-être également utiliser Headless. Et si vous avez déjà investi dans une bibliothèque de composants ou un système de conception basé sur des composants pour votre organisation et que vous avez besoin de données de WordPress, vous voudrez peut-être investir dans Headless. Si une équipe préfère JavaScript et n'aime pas construire des choses en PHP, c'est aussi une raison de considérer Headless.

Cependant, certaines raisons pour lesquelles vous ne voudrez peut-être pas devenir Headless – actuellement, cela prend un peu plus de temps de développement. Donc, si vous avez un budget inférieur ou réduisez le temps et que vous avez déjà des solutions dans WordPress traditionnel, vous ne passerez peut-être pas encore Headless. Si les administrateurs de votre site ont vraiment besoin de contrôler l'installation de plugins qui modifient le front-end, vous ne passerez peut-être pas encore Headless.

Si votre équipe préfère vraiment PHP et ne veut pas apprendre JavaScript ou d'autres interfaces, vous pouvez également vous en tenir à WordPress traditionnel. Et si vous n'êtes pas investi dans un développement basé sur des composants ou une bibliothèque basée sur des composants, si cela ne vous intéresse pas, vous pouvez vous en tenir aux workflows de développement WordPress traditionnels.

Et si vos éléments vitaux Web de base sur votre WordPress traditionnel sont vraiment bons et que vos coûts de maintenance sont très faibles pour que votre site Web fonctionne très rapidement, vous pourriez être d'accord pour vous en tenir à WordPress traditionnel. Donc, vous n'êtes pas obligé d'aller sans tête. Mais je vais vous montrer pourquoi je pense que Headless peut être bon pour certaines équipes.

Donc, si nous regardons à nouveau l'expérience du développeur WordPress, nous publions notre contenu dans un champ qui génère une grande partie de HTML. Et même si nous utilisons l'éditeur Gutenberg, qui contient ces blocs granulaires, le résultat final est un gros morceau de HTML. Et donc, que nous publions dans Gutenberg ou dans l'éditeur classique traditionnel, ce morceau de HTML est envoyé via PHP à notre thème et nous avons une page globale qui charge notre HTML, notre CSS et notre JavaScript. Et ces actifs sont appliqués à la page globalement.

Ainsi, les développeurs WordPress découpleront généralement notre développement en fonction des types de fichiers, nous mettrons donc notre CSS dans des fichiers séparés qui sont appliqués globalement à la page, ou le HTML sera écrit en PHP, et extraira les données dont nous avons besoin de WordPress, puis JavaScript le fera être écrit souvent avec jQuery dans des fichiers séparés. Et donc ces trois choses vont se réunir pour construire la page.

Le problème est qu'ils ne sont pas isolés, ils s'appliquent à toute la page. Donc, parfois, vous pouvez faire un changement. Comme si cela m'était arrivé. Une fois, j'ai modifié un style dans le pied de page d'un site à la demande de mon responsable et trois jours plus tard, il a été signalé que le style avait changé ailleurs sur le site à cause de cette révision du code d'accès. Nous l'avons passé.

Tout d'un coup, quelque chose d'autre sur le site a été cassé et cela parce que CSS est appliqué globalement et peut avoir un impact sur des choses que vous ne réalisez pas. Il y a une nouvelle tendance, cependant, au cours des dernières - je ne sais pas - sept, huit ans peut-être appelée architecture à base de composants. Cela nous permet de construire des éléments spécifiques de notre application dans ce qu'on appelle des composants.

Et nous pouvons coupler notre JavaScript, notre HTML, notre CSS en petits morceaux que nous pouvons tester isolément et ainsi nous pouvons construire des morceaux de notre application. Quelques préoccupations, le balisage, les JavaScripts, les styles, et nous pouvons composer ces composants ensemble pour créer des applications plus complexes.

Et donc le développement basé sur les composants nous permet de décomposer des fonctionnalités complexes en plus petits morceaux isolés et nous pouvons les tester isolément, nous assurer qu'ils fonctionnent et ensuite nous pouvons coupler nos préoccupations qui devraient être couplées. Chaque tranche d'interface utilisateur a une responsabilité spécifique. S'il s'agit d'une carte image, elle peut être responsable du rendu de l'image à une certaine taille avec une URL spécifique.

Il a donc des dépendances de balisage. Il a des dépendances de style. Il peut avoir des interactions avec état. Ceux-ci sont tous concernés par ce composant spécifique. Nous pouvons donc coupler notre balisage, notre JavaScript et notre CSS en un seul endroit, le tester et nous assurer qu'il fonctionne bien. Et à cause de cela, nous pouvons ensuite réutiliser ces composants dans notre application, ou nous pouvons même réutiliser nos composants dans tous les projets.

Il y a donc une tendance appelée bibliothèques de composants. Il y a des projets comme Material UI, ou des composants de conception finaux, ou Chakra UI est également populaire. Et nous pouvons utiliser ces composants dans tous les projets. Et nous pouvons résoudre des problèmes centraux comme le balisage accessible. Et nous pouvons apporter des mises à jour à ceux-ci et les appliquer à plusieurs projets de notre organisation à la fois et pour cette raison - pour ces raisons, nous pouvons itérer et expédier plus rapidement souvent avec beaucoup plus de confiance.

Alors, comment pouvons-nous utiliser Headless WordPress alors ? Comme je l'ai déjà mentionné, il existe en quelque sorte deux façons d'extraire des données de WordPress et de les intégrer aux composants. L'un serait l'API REST. L'un serait WPGraphQL. Mon ami, Drake, construit des sites Headless depuis un certain temps, alors je lui ai demandé et voici ce qu'il a dit…

Il préfère WPGraphQL. C'est donc de cela que nous allons parler aujourd'hui. Alors, qu'est-ce que WPGraphQL ? Vous pourriez demander. Eh bien, c'est un plugin WordPress open-source gratuit qui fournit un schéma et une API GraphQL extensibles pour n'importe quel site WordPress. Qu'est-ce que GraphQL alors ? Eh bien, c'est un langage de requête graphique.

D'accord, Jason. Je ne comprends toujours pas ce que vous dites. Très bien, alors laissez-moi vous montrer. Donc GraphQL, la façon dont cela fonctionne est que les applications clientes envoient une requête spécifiant ce qu'elles veulent du serveur. Et une requête ressemble à ceci. Cela ressemble à des clés JSON sans valeurs. Donc, dans ce cas, la requête demande le visualiseur et sur un visualiseur, nous voulons que le champ "nom" soit renvoyé.

Et une réponse du serveur GraphQL pourrait ressembler à ceci. Ses données, clés et valeurs JSON réelles correspondent à la forme de la demande. Donc, dans ce cas, nous obtenons le nom, ou nous obtenons le spectateur avec le nom de Jason Bahl. Ainsi, GraphQL permet aux applications clientes d'extraire des arbres du graphique de données d'application.

Et ce à quoi cela ressemble visuellement, c'est quelque chose comme ça. Nous pouvons entrer dans le graphique, disons, ajouter un visualiseur ou un champ utilisateur ou un nœud. Et ce nœud pourrait avoir une propriété comme un nom Jason. Et ce nœud peut avoir des connexions à d'autres nœuds du graphique comme un avatar, qui peut avoir une propriété comme une URL d'image.

Et cet utilisateur peut avoir des connexions à d'autres nœuds comme la publication qu'il a créée. Et ces messages peuvent eux-mêmes avoir des propriétés comme un titre, bonjour le monde ou au revoir Mars. Et ces messages peuvent avoir des liens avec d'autres nœuds du graphique, tels que des catégories avec leurs propres titres comme les actualités ou les sports. Et ces catégories peuvent également avoir des connexions avec d'autres nœuds, comme plus de publications. Et ces messages pourraient avoir présenté des images et ainsi de suite et ainsi de suite. Nous avons donc ce gros graphique de données dont nous pouvons demander des morceaux avec GraphQL.

Et nous pouvons donc utiliser des outils dans l'administrateur GraphQL ou dans l'administrateur WordPress. Il existe un outil appelé GraphiQL, où je peux composer une requête. Et ici, je sélectionne le champ Viewer avec des sous-sélections, le nom, l'avatar, l'URL et lorsque nous exécutons cela, nous obtenons les champs que nous demandons et si visuellement cette requête ressemble un peu à ceci.

Nous sommes entrés dans le graphique et nous avons demandé un utilisateur. Nous avons demandé le nom de l'utilisateur, l'avatar connecté dans l'URL de l'avatar. Nous avons tout ce graphique de données à notre disposition, mais nous ne demandons qu'un ensemble spécifique de données et en réponse, nous avons obtenu ce recul spécifique. Et alors nous pouvons prendre– nous pouvons maintenant utiliser des composants.

J'ai donc parlé des avantages du développement basé sur les composants, et je veux vous montrer cela en action. Et c'est donc ce que j'appellerais un élément de présentation. C'est donc un composant de la carte qui est responsable. Il a une responsabilité de rendre cette carte avec une image et un titre.

Et nous pouvons regarder le code et nous voyons que nous avons un certain contrôle de style. Nous pouvons définir la largeur, nous pouvons lui transmettre l'image que nous voulons et nous pouvons lui transmettre le titre. Nous pouvons donc réutiliser ce composant tout au long de notre projet. Et ce composant a toutes les dépendances dont nous avons besoin. Il a le HTML à rendre. Il a les styles. Nous avons un certain contrôle de style ici. Il a des composants avec état comme l'état de survol et ainsi de suite.

Il s'agit donc d'un composant isolé que nous pouvons réutiliser et avec GraphQL maintenant, nous pouvons prendre la requête que nous venons de composer dans l'administrateur WordPress en utilisant GraphQL et nous pouvons l'intégrer et avoir un composant de carte de visionneuse maintenant. Nous pouvons donc écrire notre requête, la coupler avec notre composant de carte et maintenant elle complète le composant.

Nous avons notre HTML, CSS notre JavaScript. Et grâce aux données, nous avons maintenant quelque chose à rendre avec les données que nous avons demandées. Alors maintenant, nous pouvons l'utiliser dans toute notre application et il y a une fonctionnalité de GraphQL appelée fragments et cela nous permet de prendre nos requêtes GraphQL et de les diviser en morceaux réutilisables.

Donc, dans ce cas, je crée un fragment de carte de profil utilisateur, et je spécifie le nom, l'avatar et l'URL, puis j'utilise ce fragment dans une requête plus grande. Lorsque nous exécutons, nous obtenons les résultats que nous attendons. Nous pouvons maintenant prendre ce fragment, le mettre dans un composant. Nous avons maintenant un composant différent appelé la carte de profil utilisateur.

Cette carte de profil utilisateur spécifie que chaque fois que nous interrogeons un utilisateur, nous devons obtenir le nom, l'avatar et l'URL de l'avatar à utiliser dans le composant. Nous avons donc maintenant ce composant réutilisable que partout dans notre application nous demandons un utilisateur, nous pouvons obtenir les données nécessaires pour rendre cette carte réutilisable avec l'avatar et le nom de l'utilisateur.

Et donc cela peut maintenant être introduit et utilisé dans de plus grandes parties de notre application. Voici donc la requête que nous avions avant la requête du spectateur en utilisant le fragment que nous importons à partir d'un composant de carte de profil utilisateur réutilisable. Et puis nous le sortons dans un composant de carte de visionneuse et maintenant nous pouvons le réutiliser dans notre application.

Nous pouvons faire de plus grandes parties de notre application qui s'appuient sur cette carte d'utilisateur ou la carte d'auteur. Nous pouvons donc maintenant avoir plusieurs composants comme le composant de titre de blog qui est responsable du titre. Nous pouvons avoir une carte de profil utilisateur que nous venons de créer et qui affiche le profil de l'utilisateur. Nous pouvons avoir un composant de contenu ou d'extrait qui est responsable du balisage et des données pour cette partie de notre application.

Et oui, nous pouvons construire ces petits composants qui sont responsables du balisage, du CSS et des données nécessaires pour construire cette application. Et nous pouvons les composer ensemble. Nous pouvons les tester isolément, les tester également en tant qu'unités plus grandes. Nous pouvons donc également l'utiliser dans divers modèles.

Nous pouvons utiliser ces composants réutilisables pour un article de blog ou notre rôle de blog où nous avons différents auteurs, mais nous pouvons utiliser le même composant pour les rendre. Nous pouvons l'utiliser pour l'autre page d'archives. Très similaires aux parties de modèles WordPress, nous pouvons diviser nos applications Headless en petits morceaux, mais nous avons l'avantage de coupler notre technologie ensemble.

C'est donc un peu le développeur Headless WordPress qui expérimente la conception basée sur les composants et les avantages de cela. Alors maintenant, en ce qui concerne Gutenberg, en particulier, pourquoi considérez-vous WordPress sans tête avec Gutenberg en particulier ? Eh bien, si votre équipe utilise déjà Headless WordPress, éventuellement avec des champs personnalisés avancés et des champs flexibles, et que vous souhaitez mettre à jour l'expérience de l'éditeur pour utiliser Gutenberg, c'est évidemment l'une des raisons pour lesquelles vous pourriez utiliser Headless avec Gutenberg.

Si vous souhaitez bénéficier des composants de construction utilisés dans l'administration et des composants utilisés dans le front-end, c'est une bonne raison d'envisager d'utiliser Headless avec Gutenberg, car l'éditeur back-end Gutenberg de l'éditeur de blocs est entièrement basé sur les composants. Vous voudrez peut-être tirer parti de la saisie structurée. chaque bloc dans l'admin a des champs qui sont structurés.

Vous disposez d'attributs spécifiques que vous pouvez contrôler au niveau du champ. Et vous voudrez peut-être également bénéficier de cette sortie structurée pour vos composants. Et comme je l'ai mentionné, vous voudrez peut-être réutiliser des composants et des blocs dans plusieurs projets. Par exemple, vous souhaiterez peut-être disposer d'une bibliothèque de blocs que votre agence a créée et qui résout des problèmes tels que l'accessibilité et les problèmes de balisage spécifiques que vous souhaitez utiliser dans tous les projets. Et vous pouvez ensuite les mettre à jour dans tous vos projets, et pas seulement dans un projet individuel.

C'est donc une partie où les thèmes enfants de WordPress peuvent être difficiles à mettre à l'échelle, car vous devez vous rendre sur chaque site et mettre à jour le balisage et ainsi de suite sur chaque site. Eh bien, ici, vous pouvez utiliser des bibliothèques de blocs en tant que dépendances NPM et les mettre à jour dans votre organisation.

Donc, actuellement, l'état du développement de WordPress avec Gutenberg est que nous avons des blocs sur le backend, qui sont basés sur des composants. Nous pouvons créer nos propres blocs personnalisés ou utiliser des blocs WordPress de base. Mais la sortie en PHP est, comme je l'ai mentionné, ce gros morceau de HTML et alors comment pouvons-nous passer de l'obtention de ce bloc de HTML à des composants sur le backend qui sont également transférés vers des composants sur notre front-end ?

Nous allons donc examiner quelques options pour extraire les données de Gutenberg de WordPress et les intégrer aux composants. Donc, une option consiste à obtenir le contenu au format HTML. Nous pouvons donc interroger notre contenu WordPress en HTML, puis analyser ce HTML en composants. Ou nous pouvons interroger des blocs en tant que types GraphQL. Nous pouvons donc - cela nous permet d'interroger une liste de blocs, chaque bloc serait un type GraphQL que nous pouvons mapper à un composant.

Le contenu est donc HTML. C'est quelque chose que nous pouvons faire dans le noyau WPGraphQL aujourd'hui. Si vous souhaitez interroger des blocs en tant que types GraphQL individuels, il existe actuellement deux options. Nous avons l'extension GraphQL pour Gutenberg, qui est une extension communautaire, puis nous avons WPGraphQL Block Editor, qui est un plugin bêta sur lequel je travaille personnellement.

Et regardons donc ces options. Dans le noyau WPGraphQL, nous pouvons interroger le contenu au format HTML et analyser les composants. À quoi cela ressemble, c'est que nous interrogeons quelque chose comme un message, et nous pouvons demander des champs comme l'ID et le titre ou le contenu. Et le contenu va renvoyer une grosse chaîne, un gros morceau de HTML, puis nous pourrons analyser ce HTML et mapper différents nœuds DOM sur différents composants.

Comme dans ce cas sur wpgraphql.com, le lien sur la gauche est vers le code où cela se produit réellement. Je prends le balisage renvoyé par WPGraphQL et je l'analyse, recherche des nœuds HTML spécifiques et le convertis en composants React. Je peux donc avoir des éléments interactifs comme ce bloc de code, qui effectue la coloration syntaxique et permet aux utilisateurs de cliquer sur Copier, puis je peux également analyser et créer une table des matières, par exemple. C'est donc une approche. Et je l'utilise dans wpgraphql.com en production aujourd'hui.

Certaines choses que vous voudrez peut-être considérer si vous suivez cette voie, les charges utiles HTML peuvent être imprévisibles. Les modifications apportées au serveur, telles que l'installation d'une nouvelle bibliothèque de blocs ou divers codes HTML que les éditeurs peuvent intégrer au contenu, sont imprévisibles. Il pourrait donc être très difficile à analyser. Vous ne pouvez pas interspecter les changements. En tant que développeur client, vous ne pouvez pas voir ce qui a changé, il suffit donc de prendre en compte.

Je dirais que cette approche fonctionne mieux pour les équipes qui ont un contrôle très étroit sur l'administrateur WordPress et le front-end. Donc, si vous êtes une personne seule ou une petite équipe qui travaille sur le backend et le front-end de WordPress, cela pourrait bien fonctionner pour vous car vous pouvez contrôler un peu mieux l'entrée et la sortie.

L'une des autres options, WPGraphQL pour Gutenberg, est un plugin géré par la communauté. Et cela vous permettra d'interroger des blocs de contenu, chaque bloc comme son propre type GraphQL. La façon dont cela fonctionne est une page de paramètres, vous devez entrer uniquement les blocs en tant que schéma, donc cela ouvre Gutenberg dans un iframe invisible, obtient le registre de blocs du client JavaScript et l'envoie au serveur.

Et puis nous pouvons utiliser GraphQL pour interroger nos blocs en tant que types spécifiques, et nous pouvons utiliser des fragments comme je l'ai montré plus tôt et nous pouvons utiliser ces fragments pour mapper aux composants de notre front-end. C'est donc une option. Certaines considérations avec ce plugin, les modifications apportées au registre des blocs sont introspectables, c'est donc une bonne chose.

Les équipes travaillant sur l'application frontale peuvent utiliser l'introspection GraphQL pour voir comment le schéma change au fil du temps et elles peuvent savoir s'il y a des changements avec rupture ou de nouveaux champs qu'elles peuvent consommer. Je dirais que cette approche fonctionne un peu mieux pour les projets à plusieurs personnes ou à plusieurs équipes. Si vous avez une équipe qui travaille sur l'administrateur WordPress et une autre équipe qui travaille sur le front-end, cette approche pourrait mieux fonctionner. Ils peuvent utiliser le schéma GraphQL comme contrat entre les blocs utilisés des deux côtés.

Une chose qui est un peu intéressante est qu'elle charge des blocs dans l'iframe comme je l'ai mentionné. Et pour cette raison, il ne s'adapte pas toujours à toutes les situations. Donc, si vous enregistrez des blocs sur une page spécifique ou un modèle spécifique ou un type de publication spécifique, cette méthode d'obtention de la carte de registre de blocs sur le schéma peut manquer certains blocs. Il se peut donc qu'il ne s'adapte pas à tous les projets.

Donc, le prochain projet, WPGraphQL Block Editor, c'est un plugin bêta sur lequel je travaille actuellement. Et cela vous permet également d'interroger les blocs de contenu comme leur propre type GraphQL et donc très similaire à WPGraphQL pour Gutenberg, nous pouvons écrire des fragments qui renvoient les données que nous spécifions. Et puis nous pouvons utiliser ces fragments avec nos composants sur le front-end.

Quelques considérations avec cela, c'est un plugin bêta, donc voilà. Vous bénéficiez d'une entrée structurée et d'une sortie structurée. Donc, en tant que développeur front-end, c'est une victoire à coup sûr. Cela fonctionne avec les blocs qui sont enregistrés avec le fichier block.json. Donc, les blocs principaux de WordPress Gutenberg ont ce fichier et cela fonctionnera donc avec cette approche. De nombreux tiers n'enregistrent pas leurs blocs de cette manière, vous devrez donc mapper manuellement ces blocs.

Les blocs ne sont pas traités comme des nœuds individuels. J'aimerais traiter les blocs comme des nœuds individuels, mais il n'y a pas d'ID global, vous devez donc accéder à ces blocs en tant que parties d'objets plus gros comme une page d'affichage.

J'espère donc que vous avez appris quelque chose sur Headless WordPress, les avantages de Headless WordPress et l'utilisation de Headless WordPress avec Gutenberg. Je vous invite à essayer WPGraphQL aujourd'hui. Vous pouvez créer un compte Atlas Sandbox gratuit sur wpengine.com/atlas. Et merci d'avoir participé à ma présentation. Encore une fois, vous pouvez me trouver sur Twitter, jasonbahl, ou aussi sur Twitter @wpgraphql. Merci.