Présentation du pont React-Gutenberg : prise en charge des blocs sans tête pour une expérience d'édition encore meilleure

Vous êtes enthousiasmé par les opportunités offertes par WordPress sans tête, mais l'équipe marketing de votre client est liée à l'éditeur WYSIWYG Gutenberg.

Découvrez comment le nouveau support de bloc Gutenberg de Faust pour les projets sans tête réunit les deux pour moderniser votre développement tout en responsabilisant vos spécialistes du marketing.

Haut-parleurs:

• Teresa Gobble, ingénieur logiciel chez WP Engine
• Blake Wilson, ingénieur logiciel senior chez WP Engine

Diapositives de la session :

Transcription:

TERESA GOBBLE : Salut, les amis. Je m'appelle Teresa Gobble. Je suis un ingénieur logiciel avec WP Engine travaillant dans l'équipe Faust.

Et je suis ici avec Blake Wilson, un ingénieur logiciel senior, pour vous présenter le pont React-Gutenberg - prise en charge des blocs sans tête pour une expérience d'édition encore meilleure. Accueillir. Commençons.

Donc, aujourd'hui, nous avons beaucoup à couvrir. Tout d'abord, je vais passer en revue quelques éléments liés au problème et à la solution que nous avons pour vous, ainsi que la valeur du pont React-Gutenberg. Ensuite, nous irons à Blake, qui nous fournira une démonstration du pont React-Gutenberg en action. Ensuite, nous parlerons de quelques détails techniques. Et nous visiterons également une future feuille de route de ce que nous avons en réserve pour cela.

Voici donc le problème. Il n'existe aucun moyen simplifié de traduire les blocs Gutenberg de WordPress en un frontal sans tête. Les solutions existantes ne sont pas encore évolutives ou intuitives pour fournir une expérience de développement à laquelle les développeurs sans tête peuvent s'attendre.

Le découplage interrompt naturellement la possibilité d'utiliser le contenu du bloc Gutenberg dans l'éditeur. Et les agences se demandent comment elles s'y prennent pour faire leur propre chemin ou à partir de zéro avec peu de conseils. Et beaucoup de questions sans réponse restent pour les gens.

Qu'en est-il du style? Qu'en est-il de la réutilisabilité, des blocs dynamiques, des InnerBlocks ? Eh bien, c'est là qu'intervient le pont React-Gutenberg. C'est une solution en deux parties - premièrement, un moyen d'exposer par programme les blocs de Gutenberg afin qu'ils puissent être analysés et lus sur le frontal sans tête. Cette pièce s'appelle WPGraphQL Content Blocks.

Deuxièmement, nous avons un connecteur pour faciliter la configuration et le rendu de ces blocs dans le frontal sans tête. Et ceci est un package appelé Faust WP Blocks. Ici, vous verrez une présentation de la façon dont cela fonctionne avec ces deux éléments de solution.

Le back-end basé sur React de votre site Web a ses blocs Gutenberg, qui sont exposés par le plug-in WPGraphQL Content Blocks. Il expose le contenu block.json à WPGraphQL. Il le fournit au plugin, appelé WPGraphQL.

Et puis il s'agit du package de connecteur, qui permet la personnalisation, la découverte et le rendu des blocs. Et cela sera en fait beaucoup plus discuté au cours de la discussion technique et de la démonstration d'aujourd'hui. Alors, quel genre de valeur cela apporte-t-il à votre équipe ?

Eh bien, c'est une solution opiniâtre de bout en bout, qui réduit la complexité et l'ambiguïté. Il permet de gagner du temps de développement en suivant des conventions spécifiques. Il permet d'utiliser des blocs et des motifs de blocs en combinaison. Et il peut être réutilisé maintes et maintes fois. Maintenant que vous avez une idée du fonctionnement du pont React-Gutenberg, allons voir Blake pour en voir une démonstration en action.

BLAKE WILSON : Merci, Teresa. Salut tout le monde. Je suis Blake Wilson. Je suis un ingénieur logiciel senior ici chez WP Engine.

Et je fais partie de l'équipe Faust JS qui construit Faust. J'ai une très bonne démo pour vous aujourd'hui montrant les deux composants que nous avons construits pour aider à orchestrer ce pont React-Gutenberg. Alors allons-y.

Pour commencer, je vais vous montrer ce que j'ai ici pour ma configuration. Et puis nous pouvons entrer dans le code réel et voir ce que nous avons là. Donc, pour commencer, j'ai un site WordPress ici fonctionnant sur Local.

J'ai quelques plugins installés. J'ai donc le plugin Faust. Cela facilite les aperçus et tout ce genre de bonnes choses sur votre site Faust JS. J'ai WPGraphQL, qui est nécessaire pour transformer votre site WordPress en point de terminaison GraphQL.

Et puis j'ai les blocs de contenu WPGraphQL. C'est donc l'un des plugins que nous avons construit pour aider à faciliter ce pont React-Gutenberg. Cette solution est en deux parties principales.

Nous avons donc l'un des éléments pour exposer réellement les données du bloc Gutenberg par programme via WPGraphQL, puis une autre partie pour l'utiliser sur votre frontal Faust JS. Commençons par jeter un œil aux blocs de contenu WPGraphQL et à leur fonctionnement.

Nous allons donc entrer dans notre IDE graphique. Et j'ai cette requête configurée ici pour récupérer les données d'une page. Donc, dans ce cas, nous obtenons simplement le titre de la page.

Donc, ce que fait GraphQL Content Blocks, c'est exposer un type de blocs de contenu dans votre schéma GraphQL. Donc, si nous tapons des blocs de contenu, vous pouvez voir ici, nous obtenons des informations pour cette page donnée et tous les blocs de cette page. Passons en revue et modifions cette page et ajoutons du contenu.

Nous allons donc accéder à la page d'exemple. Et vous pouvez voir ici que nous avons une page blanche. Alors allons-y et créons des blocs. Créons quelques colonnes ici.

Et nous ferons une colonne 50/50. Ajoutons un paragraphe sur cette moitié, puis une image sur cette moitié. J'ai donc une image ici dans ma médiathèque. Allons-y et déposons ça.

Et vous pouvez voir ici, nous avons deux colonnes. Encore une fois, un paragraphe à gauche et une image à droite. Alors mettons ça à jour. Et revenons aux blocs de contenu WPGraphQL et voyons ce que nous obtenons en conséquence.

Vous pouvez donc voir ici que nous avons maintenant deux blocs de contenu. Le premier ici est une colonne de base, une colonne de base. Et puis nous obtenons du HTML rendu à l'intérieur.

Donc, la grande chose à propos des blocs de contenu WPGraphQL est que nous gérons également les InnerBlocks. Donc, vous pouvez voir ici si nous ajoutons un paramètre aux blocs de contenu appelé flat true, vous pouvez voir maintenant que nous obtenons en fait tous les blocs qui étaient même dans ces colonnes. Nous nous occupons donc également de cette affaire pour vous.

Nous obtenons une colonne principale, une colonne principale, un paragraphe principal, une image principale. Donc, tout cela est fait par programmation pour vous. Et maintenant, vous pouvez utiliser ces données de bloc sur votre front-end. Alors creusons un peu plus ici.

Disons que nous voulons certains des attributs à ce sujet. Nous pouvons l'utiliser en utilisant une union dans GraphQL. Nous allons donc faire sur l'image de base, obtenir les attributs. Et disons que nous voulons la légende, par exemple.

Donc vous pouvez voir ici qu'il n'y a pas de légende. Revenons à notre exemple de page. Nous allons continuer et ajouter une légende ici. Ma légende. Mettez ça à jour.

Et si nous actualisons cette requête, nous pouvons voir maintenant que nous obtenons ma légende en tant qu'attribut approprié dans les blocs de contenu WPGraphQL. C'est donc la partie 1 de la solution. Maintenant, nous pouvons réellement obtenir toutes nos données Gutenberg Block et les utiliser pour les consommer sur notre front-end.

Passons donc à VS Code, et nous verrons comment nous nous attaquons à cette pièce. Voici donc un exemple de projet Faust JS que j'ai mis en place. C'est très simple. Il est basé sur le Faust Scaffold Blueprint, mais avec une configuration supplémentaire pour gérer ces blocs.

Donc, si nous jetons un coup d'œil au package JSON, vous pouvez voir ici que nous avons quelques dépendances ici, certains des packages Faust habituels, comme core et CLI. Nous avons également des blocs Faust VP. C'est donc l'un de ces packages qui fournit toutes nos fonctions d'assistance.

Nous avons également des dépendances WordPress pour la gestion des styles, etc. Vous remarquerez également ici que nous avons ce répertoire WP Blocks. C'est donc là que vivent tous nos blocs pour notre front-end et agit comme un registre pour tous les blocs que nous utilisons sur notre front-end.

Vous pouvez voir que nous avons un fichier index.js. Et c'est essentiellement un objet qui détermine tous les blocs que nous utilisons sur notre front-end. Vous pouvez donc voir ici que nous avons un paragraphe principal, une colonne principale, des colonnes principales et une image principale.

En termes de mise en place, il y a deux éléments principaux dont nous allons parler. L'un est donc le fournisseur de blocs WordPress et le visualiseur de blocs WordPress. Voyons donc à quoi cela ressemble en action. Jetons d'abord un coup d'œil au fournisseur de blocs WordPress.

Et cela va être disponible dans pages_app. Vous pouvez donc voir ici que nous avons ce composant, ce fournisseur, le fournisseur de blocs WordPress. Et il accepte un accessoire de configuration qui accepte les blocs. Vous pouvez donc voir ici que nous importons des blocs de WP Blocks, l'index de ce répertoire, et nous le transmettons dans l'objet de configuration.

Donc, essentiellement, ce que cela signifie, c'est que le fournisseur de blocs WordPress enveloppe l'ensemble de votre application et donne un contexte pour tous ces blocs à l'ensemble de votre application. Passons maintenant aux modèles WP dans notre modèle singulier. Et vous pouvez voir ici que nous appelons la visionneuse de blocs WordPress avec un accessoire de blocs de contenu. Ce sont donc les données de bloc que nous récupérons de WPGraphQL.

Très bien, ça suffit pour la configuration. Faisons tourner cela et voyons à quoi cela ressemble en action. Je vais donc exécuter NPM run dev, qui mettra en place un environnement de développement sur localhost 3000. Et la page sur laquelle nous travaillions auparavant était une page d'exemple de barre oblique, donc je vais visiter la page d'exemple de barre oblique localhost 3000 pour voir ces Gutenberg Blocs que nous avons mis en place auparavant.

Vous pouvez donc voir ici que nous avons les blocs qui sont identiques dans notre éditeur Gutenberg. Revenons donc à notre éditeur Gutenberg pour un exemple de page. Et vous pouvez voir que nous avons nos deux colonnes ici, c'est mon paragraphe, puis notre image, qui correspond à ce que nous avons sur notre front-end ici.

Donc, vous dites peut-être que ça a l'air génial et tout, mais pouvons-nous modifier les styles ? Pouvons-nous changer la taille de la police ? Vous pouvez certainement.

Revenons donc à notre éditeur Gutenberg et apportons quelques modifications à ces blocs. Ajoutons donc ici une couleur de fond à notre paragraphe. Modifions également la taille en grand. Pour cette image ici, rendons-la arrondie.

Retirons la légende. Et nous mettrons à jour cela. Et vous pouvez voir ici que ces styles s'appliquent désormais. Et vous pouvez les voir sur votre front-end.

Nous redonnons donc vraiment l'expérience d'éditeur que vous n'attendez pas dans WordPress à votre site WordPress sans tête. Une autre grande chose à ce sujet est que maintenant que vous obtenez des données de programmation pour ces blocs, vous pouvez créer votre composant React avec des fonctionnalités spécifiques au framework, comme l'image suivante. Maintenant, au lieu de simplement rendre le HTML que vous récupérez de WPGraphQL, nous pouvons maintenant utiliser ces données programmatiques pour créer un composant qui rend toutes nos images dans Gutenberg avec l'image suivante, nous donnant un chargement paresseux, de meilleures performances et de meilleures images optimisées. dans l'ensemble, créer une meilleure expérience utilisateur pour nos utilisateurs.

Alors c'est super. Nous voyons exactement ce que nous attendons dans notre éditeur Gutenberg, mais disons que nous ajoutons un composant qui n'est peut-être pas encore pris en charge, ou que nous n'avons pas configuré dans notre site Faust. Alors allons-y et créons un nouveau composant ici. Nous utiliserons le tableau.

Et nous ferons deux rangées – rangée 1, rangée 2. Allez mettre à jour ça. Et si nous regardons en arrière dans notre code ici, nous pouvons voir que nous avons défini quatre blocs : paragraphe principal, colonne principale, colonnes principales et image principale. Nous n'avons pas de table de base ici.

Alors, que va-t-il se passer lorsque nous afficherons cette page ? Nous allons jeter un coup d'oeil. Nous allons donc revenir à la page d'exemple sur notre frontal Faust. Et vous pouvez voir que nous obtenons toujours un tableau ici avec la ligne 1 et la ligne 2.

En effet, si le bloc n'est pas encore défini dans votre projet Faust JS, nous effectuerons une solution de repli intelligente et intelligente vers le rendu HTML. De cette façon, vous ne voyez pas de contenu indéfini, nul ou tout simplement pas de contenu. À tout le moins, vous récupérez le rendu HTML d'origine.

Avec tout cela à l'esprit, examinons ce qu'il faut réellement pour créer un bloc - à quoi il ressemble réellement. Nous allons donc revenir à VS Code ici. Et choisissons l'image principale par exemple.

Vous pouvez donc voir ici qu'il ne s'agit que d'un composant React traditionnel. Nous l'appelons l'image de base. Et il accepte les accessoires, comme tout autre composant React.

Il y a essentiellement deux pièces dans un bloc ici. Nous avons donc le composant React réel, qui est la couche de présentation. Et puis nous obtenons les block.fragments, qui sont les données nécessaires à l'exécution de ce bloc.

Vous pouvez donc voir ici que nous créons un fragment, fragment d'image principale sur l'image principale. Et nous obtenons ces attributs - les attributs dont nous avons besoin pour rendre ce bloc. Vous pouvez donc voir que nous obtenons le texte alternatif, la source, la légende, le nom de la classe, la largeur, la hauteur, etc.

Et ensuite, ce que nous pouvons faire, c'est appliquer ces attributs dans notre logique React actuelle. Ainsi, tous les champs demandés ici sont alors disponibles dans les accessoires. Vous pouvez donc voir props.attributes sortir, qui sont les attributs que nous avons demandés ici, attributs.alt, attributs.source, etc. C'est donc un excellent moyen de regrouper toutes les données requises pour votre bloc dans le même fichier.

Cela garantit que vous ne demandez que les données dont vous avez besoin et que vos demandes sont agréables et performantes. Nous avons également quelques fonctions d'assistance dans cet exemple de projet. Vous pouvez voir qu'il y en a quelques-uns ici - obtenez des styles et obtenez des accessoires de la taille d'une image.

Donc, il s'agit essentiellement de prendre ces styles de WordPress et de les combiner dans un objet de styles réel que React peut utiliser. Actuellement, les styles sont pris en charge pour les styles en ligne. Vous pouvez également obtenir des feuilles de style globales, mais nous travaillons actuellement à la prise en charge de theme.json.

Alors Teresa en parlera un peu dans notre future feuille de route. Mais idéalement, il arrivera un moment où nous pourrons obtenir tous nos styles et remplissages, marges, etc. à partir de theme.json et les appliquer ici dans le frontal sans tête. Avec tout cela à l'esprit, entrons dans une discussion technique rapide avec Teresa et moi pour parler de là où nous en sommes aujourd'hui avec cette fonctionnalité, et où nous prévoyons d'aller à l'avenir.

TERESA GOBBLE : Merci pour cette démonstration, Blake. C'était génial. Allons-y et entrons dans quelques détails techniques maintenant, et discutons de la façon dont cela fonctionne. Donc, le premier que j'ai pour vous est, quelles sont les exigences pour utiliser les blocs de contenu WPGraphQL ?

BLAKE WILSON : Ouais, ouais. Excellente question, Thérèse. Ainsi, la seule exigence pour utiliser le plugin est d'avoir également installé WPGraphQL. Évidemment, si vous voulez que votre site s'interface avec Faust JS, vous pouvez installer le paquet de blocs Faust JS, qui aidera à faciliter le rendu et toutes ces bonnes choses sur le front-end sans tête. Mais pour exposer réellement les données de bloc, tout ce dont vous avez besoin est WPGraphQL et le plugin WP GraphQL Content Blocks.

TERESA GOBBLE : Génial. Comment les données de bloc sont-elles également collectées ?

BLAKE WILSON : Oui, donc toutes les données de bloc sont collectées par n'importe quel bloc de WordPress qui utilise la fonction de type de bloc de registre. Ainsi, à peu près tous les blocs que vous utilisez et qui s'interfacent avec cette fonction apparaîtront dans les blocs de contenu. Et la grande chose à ce sujet est qu'il relaie avec le fichier block.json et auto-décrit et auto-documente automatiquement tous ces champs. Vous avez donc une documentation tout en un.

TERESA GOBBLE : Oh, génial. Quel gain de temps. Une autre chose dont j'aimerais que vous parliez un peu plus est ce qui se passe avec un bloc non pris en charge ? Que se passe-t-il lorsqu'un bloc non pris en charge est interrogé ?

BLAKE WILSON : Oui, c'est une autre excellente question. Il y a deux scénarios réels qui peuvent se produire ici. Il peut donc y avoir un cas où, disons que vous avez un bloc dans vos données de publication qui a depuis été supprimé de WordPress.

C'était peut-être un bloc tiers qui a été supprimé. Il s'agit donc d'un cas de bloc non pris en charge qui n'est pas pris en charge à la fois dans le frontal Faust et dans le registre WordPress. Dans ce cas, nous renvoyons en fait un bloc aux blocs de contenu appelé bloc indéfini ou bloc inconnu afin que vous puissiez le saisir correctement dans votre frontal sans tête. Et puis la deuxième partie est si un bloc dans le registre WordPress est pris en charge, mais il n'est pas encore pris en charge dans votre frontal Faust JS, dans ce cas, ce que nous faisons, c'est que nous revenons au HTML rendu. De cette façon, à tout le moins, vous avez rendu le HTML qui s'affiche, ni nul, ni indéfini, ni aucune valeur de ce genre.

TERESA GOBBLE : Oh, génial. Et cela m'amène en fait à ma prochaine question. En ce qui concerne les plugins tiers dans un site Web découplé sans tête, pouvez-vous utiliser un plugin tiers en utilisant le plugin WPGraphQL Content Blocks ? Comment tout cela fonctionne-t-il ensemble ?

BLAKE WILSON : Ouais, ouais. Ainsi, pour tout plugin tiers, revenant à cette première ou deuxième question, tant qu'il s'interface avec la fonction de type de bloc enregistré dans WordPress, ce bloc sera automatiquement exposé aux blocs de contenu WPGraphQL. Ainsi, tant que ces données sont rendues, vous pouvez ensuite créer le bloc dans votre frontal Faust JS. Et la grande chose à ce sujet est disons que vous avez un bloc tiers pour un carrousel. Une fois que vous l'avez créé une fois dans votre frontal Faust JS, vous pouvez ensuite le réutiliser dans d'autres projets à l'avenir.

TERESA GOBBLE : Oh, super. C'est là qu'intervient la réutilisation. Et avec ce plugin, vous pouvez en fait combler une partie de cet écart avec des plugins tiers qui ne fonctionnent pas immédiatement avec les sites Web découplés.

De plus, si vous regardez dans le chat maintenant, nous avons en fait un tutoriel conçu pour aider les gens à créer un bloc à partir d'un plugin tiers. Donc, vous regardez dans le chat maintenant, vous pourrez voir cela et cliquer dessus. Donnez-lui un signet.

Alors, comment gérez-vous les blocs dans les blocs ? Cela peut être très délicat. Pouvez-vous nous expliquer un peu à quoi cela ressemblerait?

BLAKE WILSON : Bien sûr, oui. Nous avons donc ce drapeau ou ce paramètre lorsque vous interrogez des blocs de contenu appelés plats. Et cela accepte une valeur vraie ou fausse. Et donc, lorsque cela est fourni comme vrai, vous obtiendrez en fait un tableau plat ou une liste plate de tous les blocs de cette page, qu'il s'agisse d'une colonne, d'une image ou d'un paragraphe.

Vous aurez une liste complète de tous les blocs interrogés sur cette page avec deux propriétés supplémentaires. L'un est l'ID de nœud. C'est donc l'ID réel de ce bloc particulier. Et puis vous aurez également l'ID parent, qui est le parent de ce bloc. Donc, ce que vous pouvez faire ensuite, c'est reconstruire cela dans une liste hiérarchique réelle sur votre front-end, résolvant à peu près l'énigme du bloc interne comme nous l'avons vu dans Gutenberg auparavant.

TERESA GOBBLE : Génial. Donc, en fait, il existe une option, lors de la récupération des blocs de contenu, que vous pouvez spécifier pour renvoyer une liste plate de blocs dans leurs ID enfant parent appropriés ?

BLAKE WILSON : Ouais, ouais, exactement.

TERESA GOBBLE : Génial. Nous avons également un autre didacticiel ici dans le chat, encore une fois, pour que les blocs de contenu WPGraphQL examinent également cette fonction particulière. Je voulais donc vous poser une autre question sur le style – donc le style avec des feuilles de style globales, en ligne, quelle est l'approche là-bas ? Comment le style est-il géré ?

BLAKE WILSON : Ouais, ouais. Le style est donc probablement l'une des plus grandes poussées que nous essayons de rechercher en ce moment. Dans l'exemple que je viens de montrer, cela utilise des styles en ligne.

Les styles globaux, les feuilles de styles globales sont également pris en charge. Et je pense que vous en parlerez ensuite dans la feuille de route. Mais idéalement, nous voulons également prendre en charge la prise en charge de theme.json, où nous pouvons obtenir des marges, des rembourrages, des couleurs et toutes ces bonnes informations à partir de theme.json, puis les appliquer. Nous travaillerons donc là-dessus dans notre prochaine phase de développement.

TERESA GOBBLE : Génial. Merci de nous avoir guidés à travers cela. Je sais que beaucoup de gens sont vraiment excités à ce sujet. Alors, comment empêcher l'éditeur d'utiliser des blocs qui ne sont pas pris en charge ?

BLAKE WILSON : Ouais, ouais. Il existe donc un plugin. Ça dépend. Si vous utilisez des blocs tiers, certains d'entre eux ont déjà cette fonctionnalité intégrée.

Mais si ce n'est pas le cas, il existe un plug-in appelé visibilité des blocs, que vous pouvez réellement basculer entre des blocs spécifiques du point de vue de l'éditeur. Supposons donc que vous ayez un bloc carrousel qui n'a pas encore été implémenté sur votre site Faust. Vous pouvez installer la visibilité des blocs et la décocher afin que l'éditeur ne l'utilise pas tant qu'elle n'est pas prise en charge ou en cours de développement.

TERESA GOBBLE : Oh, génial. Donc, cette visibilité de bloc de plugin peut réellement basculer, masquer, afficher des blocs spécifiques ?

BLAKE WILSON : Ouais, ouais, exactement. De cette façon, vous avez un nombre limité de blocs que vous avez pris en charge, à la fois dans votre côté WordPress et votre site sans tête afin que les éditeurs sachent, OK, nous pouvons l'utiliser avec certitude qu'il sera pris en charge sur le l'extrémité avant.

TERESA GOBBLE : Oh, cela ressemble à une livraison plus propre à coup sûr. OK cool. Dernière question pour vous. Ces blocs frontaux correspondent-ils à l'éditeur de l'éditeur ?

BLAKE WILSON: Ouais, super légende. Donc pas encore. C'est quelque chose sur lequel nous allons travailler à l'avenir, mais pour le moment, ces blocs sont pris en charge pour le frontal sans tête.

Si vous avez un bloc personnalisé que vous avez créé dans WordPress, si vous utilisez la commande NPX create block, vous devrez toujours prendre en charge cette vue côté WordPress. Mais c'est quelque chose sur lequel nous travaillons. Nous l'avons dans notre feuille de route.

TERESA GOBBLE : Oh, génial. D'ACCORD. Merci d'avoir discuté de ces points avec nous, Blake. Cela a été très utile, et la démo aussi.

Allons de l'avant et changeons de vitesse et parlons un peu plus de cette feuille de route du projet. Nous avons en fait cinq phases, dont deux sont déjà terminées - la phase 1 et la phase 2. Phase 1, nous avons vu une mise en œuvre d'une méthode pour déconstruire puis reconstruire un bloc efficacement.

Après cela, nous sommes passés à la phase 2, qui était axée sur une intégration plus étroite de Faust avec Gutenberg Blocks afin de garantir que les gens aient tous accès aux différents utilitaires et fonctions d'assistance qui s'y trouvent. Cette prochaine phase sur laquelle nous sommes actuellement, la phase 3, nous nous concentrons sur la fourniture d'un support theme.json et de bibliothèques de blocs réutilisables, comme Blake l'a mentionné lors de notre discussion technique.

Une fois que nous aurons terminé, les phases 4 et 5 auront lieu. La phase 4 se concentre sur l'amélioration de l'expérience de développement et d'édition existante, ainsi que la phase 5, qui se concentre sur la prise en charge de l'écosystème plus large au-delà du cœur de WordPress. Nous sommes vraiment ravis de ces phases à venir, et nous espérons que vous nous contacterez et que vous consulterez également notre article de blog pour vous tenir au courant de la feuille de route.

Vous pouvez voir un lien dans le chat ci-dessous vers nos articles de blog si vous y jetez un œil. Allez-y et mettez-les en signet. Eh bien, merci à tous de vous être joints à nous pour notre discussion sur le pont React-Gutenberg. Je veux ramener Blake à l'écran ici afin qu'il puisse également dire merci et nous donner un peu plus d'informations sur l'endroit où vous pouvez aller si vous avez des questions persistantes après cela.

BLAKE WILSON : Oui, merci, Teresa, et merci à tous ceux qui ont rejoint cette session aujourd'hui et qui ont regardé. Nous sommes ravis de recevoir les commentaires de la communauté sur cette fonctionnalité pour que vous puissiez tous commencer à l'essayer.

Donc, si vous l'aimez, nous avons l'exemple de projet dans le lien du chat. Nous avons également un lien dans le chat pour notre Discord sans tête, donc juste un endroit où vous et d'autres développeurs sans tête partageant les mêmes idées pouvez vous joindre et discuter des fonctionnalités et des versions à venir dans l'espace sans tête. Alors encore merci à vous tous. Nous apprécions vraiment cela.