Presentazione del ponte React-Gutenberg: supporto dei blocchi senza testa per un'esperienza di editing ancora migliore

Sei entusiasta delle opportunità offerte da WordPress headless, ma il team di marketing del tuo cliente è legato all'editor WYSIWYG Gutenberg.

Scopri come il nuovo supporto del blocco Gutenberg di Faust per i progetti headless unisce i due per modernizzare il tuo sviluppo e allo stesso tempo potenziare i tuoi esperti di marketing.

Altoparlanti:

• Teresa Gobble, Ingegnere del software presso WP Engine
• Blake Wilson, ingegnere informatico senior presso WP Engine

Slide della sessione:

Trascrizione:

TERESA GOBBLE: Salve gente. Mi chiamo Teresa Gobble. Sono un ingegnere del software con WP Engine che lavora nel team Faust.

E sono qui con Blake Wilson, un ingegnere informatico senior, per presentarti React-Gutenberg Bridge, il supporto dei blocchi senza testa per un'esperienza di editing ancora migliore. Benvenuto. Iniziamo.

Quindi oggi abbiamo molto da coprire. Prima di tutto, esaminerò un paio di cose relative al problema e alla soluzione che abbiamo per te, oltre al valore del ponte React-Gutenberg. Poi andremo da Blake, che ci fornirà una demo del ponte React-Gutenberg in azione. Successivamente, parleremo di un paio di dettagli tecnici. E visiteremo anche una roadmap futura di ciò che abbiamo in serbo per questo.

Quindi ecco il problema. Non esiste un modo semplificato per tradurre i blocchi di Gutenberg da WordPress a un front-end senza testa. Le soluzioni là fuori che esistono non sono ancora scalabili o intuitive per fornire un'esperienza di sviluppo che gli sviluppatori senza testa possono aspettarsi.

Il disaccoppiamento interrompe la possibilità di utilizzare il contenuto del blocco Gutenberg nell'editor in modo naturale. E le agenzie sono lasciate a chiedersi come fanno a fare a modo loro o da zero con poche indicazioni. E molte domande senza risposta rimangono per la gente.

E lo stile? Che dire della riusabilità, dei blocchi dinamici, degli InnerBlock? Bene, qui è dove entra in gioco il ponte React-Gutenberg. È una soluzione in due parti: in primo luogo, un modo per esporre a livello di codice i blocchi di Gutenberg in modo che possano essere analizzati e letti sul front-end senza testa. Questo pezzo si chiama WPGraphQL Content Blocks.

In secondo luogo, abbiamo un connettore per facilitare la configurazione e il rendering di quei blocchi nel front-end headless. E questo è un pacchetto chiamato Faust WP Blocks. Qui vedrai una procedura dettagliata di come funziona con entrambi questi componenti della soluzione.

Il back-end basato su React del tuo sito Web ha i suoi blocchi Gutenberg, che sono esposti dal plug-in WPGraphQL Content Blocks. Espone il contenuto block.json a WPGraphQL. Lo fornisce al plugin, chiamato WPGraphQL.

E poi arriva al pacchetto del connettore, che consente la personalizzazione, la scoperta e il rendering dei blocchi. E questo sarà effettivamente discusso molto di più durante la discussione tecnica e la demo di oggi. Quindi che tipo di valore porta questo al tuo team?

Bene, è una soluzione supponente end-to-end, che riduce la complessità e l'ambiguità. Risparmia tempo di sviluppo seguendo convenzioni specifiche. Consente di utilizzare in combinazione blocchi e modelli di blocchi. E può essere riutilizzato più e più volte. Ora che hai un'idea di come funziona il ponte React-Gutenberg, andiamo da Blake per vederne una demo in azione.

BLAKE WILSON: Grazie, Teresa. Ciao a tutti. Sono Blake Wilson. Sono un ingegnere informatico senior qui a WP Engine.

E io sono nel team di Faust JS che costruisce Faust. Oggi ho una demo davvero fantastica per te che mostra i due componenti che abbiamo creato per aiutare a orchestrare questo ponte React-Gutenberg. Quindi entriamo subito in esso.

Per iniziare, ti mostrerò cosa ho qui per la mia configurazione. E poi possiamo entrare nel codice vero e proprio e vedere cosa abbiamo lì. Quindi, per cominciare, ho un sito WordPress qui in esecuzione su Local.

Ho alcuni plugin installati. Quindi ho il plugin Faust. Questo aiuta a facilitare le anteprime e tutto quel genere di cose buone sul tuo sito Faust JS. Ho WPGraphQL, che è necessario per trasformare il tuo sito WordPress in un endpoint GraphQL.

E poi ho i blocchi di contenuti WPGraphQL. Quindi questo è uno dei plugin che abbiamo creato per facilitare questo ponte React-Gutenberg. Questa soluzione è in due parti principali.

Quindi abbiamo uno dei pezzi per esporre effettivamente i dati di Gutenberg Block a livello di codice tramite WPGraphQL, e poi un'altra parte per consumarli sul tuo front-end Faust JS. Iniziamo dando un'occhiata ai blocchi di contenuto di WPGraphQL e a come funziona.

Quindi faremo un salto nel nostro IDE grafico. E ho impostato questa query qui per prendere i dati di una pagina. Quindi in questo caso, otteniamo solo il titolo della pagina.

Quindi ciò che fa GraphQL Content Blocks è esporre un tipo di blocchi di contenuto nel tuo schema GraphQL. Quindi, se digitiamo blocchi di contenuto, puoi vedere qui, otteniamo informazioni per questa data pagina e tutti i blocchi su questa pagina. Andiamo oltre e modifichiamo questa pagina e aggiungiamo alcuni contenuti.

Quindi faremo un salto alla pagina di esempio. E puoi vedere che qui abbiamo una tabula rasa. Quindi andiamo avanti e creiamo alcuni blocchi. Creiamo alcune colonne qui.

E faremo una colonna 50/50. Aggiungiamo un paragrafo su questa metà, e poi in un'immagine su questa metà. Quindi ho un'immagine qui nella mia libreria multimediale. Andiamo avanti e inseriamo questo.

E puoi vedere qui, abbiamo due colonne. Di nuovo, un paragrafo a sinistra e un'immagine a destra. Quindi aggiorniamo questo. E torniamo a WPGraphQL Content Blocks e vediamo cosa otteniamo come risultato.

Quindi puoi vedere qui, ora abbiamo due blocchi di contenuto. La prima qui è una colonna centrale, colonna centrale. E poi otteniamo l'HTML reso al suo interno.

Quindi la cosa grandiosa di WPGraphQL Content Blocks è che stiamo gestendo anche InnerBlocks. Quindi puoi vedere qui se aggiungiamo un parametro ai blocchi di contenuto chiamato flat true, puoi vedere ora che otteniamo effettivamente tutti i blocchi che erano anche in quelle colonne. Quindi stiamo gestendo anche quel caso per te.

Otteniamo una colonna principale, una colonna principale, un paragrafo principale, un'immagine principale. Quindi tutto ciò viene fatto in modo programmatico per te. E ora puoi utilizzare questi dati di blocco sul tuo front-end. Quindi scaviamo un po' più a fondo qui.

Diciamo che vogliamo alcuni degli attributi su questo. Possiamo usarlo usando un'unione in GraphQL. Quindi faremo sull'immagine principale, otterremo gli attributi. E diciamo che vogliamo la didascalia, per esempio.

Quindi puoi vedere che qui non ci sono didascalie. Torniamo alla nostra pagina di esempio. Andremo avanti e aggiungeremo una didascalia qui. La mia didascalia. Aggiornalo.

E se aggiorniamo questa query, possiamo vedere ora che otteniamo la mia didascalia come attributo appropriato in WPGraphQL Content Blocks. Quindi questa è la parte 1 della soluzione. Ora possiamo effettivamente ottenere tutti i nostri dati Gutenberg Block e utilizzarli per consumarli sul nostro front-end.

Quindi passiamo a VS Code e vedremo come affrontiamo quel pezzo. Quindi questo è un progetto di esempio di Faust JS che ho messo insieme. È molto semplice. È basato sul Faust Scaffold Blueprint, ma con alcune configurazioni aggiuntive per la gestione di questi blocchi.

Quindi, se diamo un'occhiata al pacchetto JSON, puoi vedere qui che abbiamo alcune dipendenze qui, alcuni dei soliti pacchetti Faust, come core e CLI. Abbiamo anche i blocchi Faust VP. Quindi questo è uno di quei pacchetti che fornisce tutte le nostre funzioni di supporto.

Abbiamo anche alcune dipendenze di WordPress per la gestione degli stili e così via. Noterai anche qui che abbiamo questa directory WP Blocks. Quindi è qui che risiedono tutti i nostri blocchi per il nostro front-end e funge da registro per tutti i blocchi che usiamo sul nostro front-end.

Puoi vedere che abbiamo un file index.js. E questo è essenzialmente un oggetto che determina tutti i blocchi che stiamo usando sul nostro front-end. Quindi puoi vedere qui, abbiamo il paragrafo principale, la colonna principale, le colonne principali e l'immagine principale.

In termini di configurazione, ci sono due parti principali di cui parleremo. Quindi uno è il fornitore dei blocchi di WordPress e il visualizzatore dei blocchi di WordPress. Quindi diamo un'occhiata a come appare in azione. Diamo prima un'occhiata al fornitore dei blocchi di WordPress.

E questo sarà disponibile in pages_app. Quindi puoi vedere qui che abbiamo questo componente, questo provider, provider di blocchi WordPress. E accetta un oggetto di configurazione che accetta blocchi. Quindi puoi vedere qui che stiamo importando blocchi da WP Blocks, l'indice di questa directory, e lo stiamo passando nell'oggetto config.

Quindi, in sostanza, ciò che questo sta dicendo è che il fornitore dei blocchi di WordPress avvolge l'intera app e fornisce un contesto per tutti questi blocchi all'intera app. Ora entriamo nei modelli WP nel nostro modello singolare. E puoi vedere qui che chiamiamo il visualizzatore di blocchi di WordPress con una prop di blocchi di contenuto. Quindi questi sono i dati del blocco che otteniamo da WPGraphQL.

Va bene, basta con la configurazione. Facciamolo girare e vediamo come appare in azione. Quindi eseguirò NPM run dev, che imposterà un ambiente di sviluppo su localhost 3000. E la pagina su cui stavamo lavorando prima era una pagina di esempio slash, quindi visiterò la pagina di esempio slash di localhost 3000 per vedere quei Gutenberg Blocchi che abbiamo impostato in precedenza.

Quindi puoi vedere qui, abbiamo i blocchi che sono gli stessi nel nostro editor Gutenberg. Quindi torniamo al nostro editor Gutenberg per la pagina di esempio. E puoi vedere che abbiamo le nostre due colonne qui, questo è il mio paragrafo, e poi la nostra immagine, che corrisponde a ciò che abbiamo sul nostro front-end qui.

Quindi potresti dire, sembra fantastico e tutto, ma possiamo modificare gli stili? Possiamo cambiare la dimensione del carattere? Certo che puoi.

Quindi torniamo al nostro editor Gutenberg e apportiamo alcune modifiche a questi blocchi. Quindi aggiungiamo un colore di sfondo qui al nostro paragrafo. Cambiamo anche le dimensioni in grandi. Per questa immagine qui, rendiamola arrotondata.

Togliamo la didascalia. E lo aggiorneremo. E puoi vedere qui che questi stili ora si applicano. E puoi vederli sul tuo front-end.

Quindi stiamo davvero restituendo l'esperienza dell'editore che non ti aspetti in WordPress al tuo sito WordPress headless. Un'altra cosa grandiosa di questo è che ora che stai ottenendo dati programmatici per questi blocchi, puoi creare il tuo componente React con funzionalità specifiche del framework, come l'immagine successiva. Ora, invece di eseguire il rendering dell'HTML che ottieni da WPGraphQL, ora possiamo utilizzare quei dati programmatici per creare un componente che esegue il rendering di tutte le nostre immagini in Gutenberg con l'immagine successiva, offrendoci caricamento lento, prestazioni migliori e immagini meglio ottimizzate nel complesso, creando una migliore esperienza utente per i nostri utenti.

Quindi è fantastico. Stiamo vedendo esattamente quello che ci aspettiamo nel nostro editor Gutenberg, ma diciamo che aggiungiamo un componente che forse non è ancora supportato, o che non abbiamo configurato nel nostro sito Faust. Quindi andiamo avanti e creiamo un nuovo componente quaggiù. Useremo la tabella.

E faremo due righe: riga 1, riga 2. Vai e aggiornalo. E se guardiamo indietro nel nostro codice qui, possiamo vedere che abbiamo definito quattro blocchi: paragrafo principale, colonna principale, colonne principali e immagine principale. Non abbiamo un tavolo principale qui.

Quindi cosa succederà quando visualizzeremo questa pagina? Diamo un'occhiata. Quindi torneremo alla pagina di esempio sul nostro front-end Faust. E puoi vedere che abbiamo ancora un tavolo qui con la riga 1 e la riga 2.

Questo perché se il blocco non è ancora definito nel tuo progetto Faust JS, faremo un ragionevole fallback intelligente all'HTML renderizzato. In questo modo, non vedrai alcun contenuto indefinito, nullo o semplicemente assente. Per lo meno, stai recuperando l'HTML renderizzato originale.

Con tutto questo in mente, diamo un'occhiata a ciò che effettivamente serve per creare un blocco: come appare effettivamente. Quindi torneremo a VS Code qui. E prendiamo ad esempio l'immagine principale.

Quindi puoi vedere qui, questo è solo un componente React tradizionale. La chiamiamo immagine centrale. E accetta oggetti di scena, proprio come qualsiasi altro componente React.

Ci sono essenzialmente due pezzi per blocco qui. Quindi abbiamo il vero componente React, che è il livello di presentazione. E poi otteniamo i block.fragments, che sono i dati necessari per l'esecuzione di questo blocco.

Quindi puoi vedere qui che stiamo creando un frammento, frammento dell'immagine principale sull'immagine principale. E stiamo ottenendo questi attributi, gli attributi di cui abbiamo bisogno per rendere questo blocco. Quindi puoi vedere che stiamo ottenendo il testo alternativo, la fonte, la didascalia, il nome della classe, la larghezza, l'altezza e così via.

E poi quello che possiamo fare è applicare quegli attributi nella nostra attuale logica React. Quindi tutti i campi richiesti qui sono quindi disponibili in oggetti di scena. Quindi puoi vedere uscire props.attributes, ovvero gli attributi che abbiamo richiesto qui, attribute.alt, attribute.source e così via. Quindi questo è un ottimo modo per collocare tutti i requisiti di dati per il tuo blocco all'interno dello stesso file.

Questo significa assicurarti di richiedere solo i dati di cui hai bisogno e assicurarti che le tue richieste siano piacevoli e performanti. Abbiamo anche alcune funzioni di supporto in questo progetto di esempio. Puoi vedere che ce ne sono un paio qui: prendi stili e ottieni oggetti di scena a grandezza d'immagine.

Quindi questi essenzialmente stanno solo prendendo questi stili da WordPress e combinandoli in un vero e proprio oggetto di stili che React può usare. Attualmente, gli stili sono supportati per gli stili incorporati. Puoi anche ottenere fogli di stile globali, ma al momento stiamo lavorando per fornire supporto per theme.json.

Quindi Teresa parlerà un po' di questo nella nostra tabella di marcia futura. Ma idealmente, arriverà un punto in cui possiamo ottenere tutti i nostri stili e padding, margini e così via da theme.json e applicarli qui nel front-end senza testa. Con tutto ciò in mente, entriamo in una breve discussione tecnica con me e Teresa per parlare di dove siamo oggi con questa funzione e dove stiamo pianificando di andare in futuro.

TERESA GOBBLE: Grazie per quella demo, Blake. È stato perfetto. Andiamo avanti ed entriamo ora in alcuni dettagli tecnici e parliamo di come funziona. Quindi il primo che ho per te è, quali sono i requisiti per utilizzare i blocchi di contenuto WPGraphQL?

BLAKE WILSON: Sì, sì. Ottima domanda Teresa. Quindi l'unico requisito per utilizzare il plug-in è installare anche WPGraphQL. Ovviamente, se vuoi che il tuo sito si interfaccia con Faust JS, puoi installare il pacchetto di blocchi Faust JS, che ti aiuterà a facilitare il rendering e tutta quella roba buona sul front-end headless. Ma per esporre effettivamente i dati dei blocchi, tutto ciò di cui hai bisogno è WPGraphQL e il plugin WP GraphQL Content Blocks.

TERESA GOBBLE: Fantastico. Come vengono raccolti anche i dati del blocco?

BLAKE WILSON: Sì, quindi tutti i dati del blocco vengono raccolti da qualsiasi blocco in WordPress che utilizza la funzione register block type. Quindi praticamente qualsiasi blocco che stai utilizzando che si interfaccia con quella funzione verrà visualizzato nei blocchi di contenuto. E la cosa grandiosa è che si inoltra con il file block.json e auto-descrive e auto-documenta automaticamente tutti quei campi. Quindi hai la documentazione tutta in una.

TERESA GOBBLE: Oh, fantastico. Che risparmio di tempo. Un'altra cosa di cui mi piacerebbe che tu parlassi un po' di più è cosa succede con un blocco non supportato? Cosa succede quando viene interrogato un blocco non supportato?

BLAKE WILSON: Sì, questa è un'altra bella domanda. Ci sono due scenari reali che possono accadere qui. Quindi potrebbe esserci un'istanza in cui diciamo che hai un blocco nei dati del tuo post che da allora è stato rimosso da WordPress.

Forse era un blocco di terze parti che è stato rimosso. Quindi questo è un caso di un blocco non supportato che non è supportato sia nel front-end Faust che nel registro di WordPress. In tal caso, in realtà restituiamo un blocco ai blocchi di contenuto chiamato blocco indefinito o blocco sconosciuto in modo che tu possa digitarlo in modo appropriato nel tuo front-end senza testa. E poi la seconda parte è se un blocco nel registro di WordPress è supportato, ma non è ancora supportato nel tuo front-end Faust JS, in tal caso, quello che facciamo è tornare all'HTML renderizzato. In questo modo, almeno, hai reso l'HTML che viene visualizzato, non nullo o indefinito o valori del genere.

TERESA GOBBLE: Oh, fantastico. E questo in realtà mi porta alla mia prossima domanda. Per quanto riguarda i plug-in di terze parti in un sito Web headless disaccoppiato, è possibile utilizzare un plug-in di terze parti utilizzando il plug-in WPGraphQL Content Blocks? Come funziona tutto ciò insieme?

BLAKE WILSON: Sì, sì. Quindi, per qualsiasi plug-in di terze parti, tornando alla prima o alla seconda domanda, purché si interfacciano con la funzione del tipo di blocco registrato in WordPress, quel blocco verrà automaticamente esposto ai blocchi di contenuto di WPGraphQL. Quindi, finché i dati vengono renderizzati, puoi quindi creare il blocco nel tuo front-end Faust JS. E la cosa grandiosa è che diciamo che hai un blocco di terze parti per un carosello. Dopo averlo creato una volta nel tuo front-end Faust JS, puoi riutilizzarlo in altri progetti in futuro.

TERESA GOBBLE: Oh, fantastico. È qui che entra in gioco il pezzo di riusabilità. E con questo plug-in, puoi effettivamente colmare parte di quel divario con plug-in di terze parti che non funzionano immediatamente con i siti Web disaccoppiati.

Inoltre, se guardi ora nella chat, in realtà abbiamo creato un tutorial per aiutare le persone a creare un blocco da un plug-in di terze parti. Quindi guarda nella chat ora, sarai in grado di vederlo e fare clic. Dagli un segnalibro.

Quindi, come gestisci i blocchi all'interno dei blocchi? Può essere davvero complicato. Puoi parlarci un po' di come sarebbe?

BLAKE WILSON: Certo, sì. Quindi abbiamo questo flag o questo parametro quando stai interrogando blocchi di contenuto chiamati flat. E questo accetta un valore vero o falso. E quindi quando questo viene fornito come vero, otterrai effettivamente un array piatto o un elenco piatto di tutti i blocchi su quella pagina, sia che si tratti di una colonna, di un'immagine o di un paragrafo.

Avrai un elenco completo di tutti i blocchi interrogati su quella pagina con due proprietà aggiuntive. Uno è l'ID del nodo. Quindi questo è l'ID effettivo di quel particolare blocco. E poi avrai anche l'ID genitore, che è il genitore di quel blocco. Quindi quello che puoi fare è ricostruirlo in un vero elenco gerarchico sul tuo front-end, risolvendo praticamente l'enigma del blocco interno come abbiamo visto prima in Gutenberg.

TERESA GOBBLE: Fantastico. Quindi, in realtà, c'è un'opzione, durante il recupero dei blocchi di contenuto, che puoi specificare per restituire un elenco semplice di blocchi all'interno dei loro ID genitore-figlio appropriati?

BLAKE WILSON: Sì, sì, esattamente.

TERESA GOBBLE: Fantastico. In realtà abbiamo anche un altro pezzo di tutorial quaggiù nella chat, ancora una volta, per i blocchi di contenuto di WPGraphQL per dare un'occhiata anche a quella particolare funzione. Quindi volevo farti un'altra domanda sul pezzo di styling, quindi lo styling con fogli di stile globali, in linea, qual è l'approccio lì? Come viene gestito lo styling?

BLAKE WILSON: Sì, sì. Quindi lo stile è probabilmente una delle maggiori spinte che stiamo cercando di ricercare in questo momento. Nell'esempio che ho appena mostrato, utilizza gli stili in linea.

Sono supportati anche stili globali e fogli di stile globali. E penso che toccherai questo prossimo nella tabella di marcia. Ma idealmente, vogliamo supportare anche il supporto theme.json, dove possiamo ottenere margini, padding, colori e tutte quelle buone informazioni da theme.json, e quindi applicarle. Quindi lavoreremo su questo nella nostra prossima fase di sviluppo.

TERESA GOBBLE: Fantastico. Grazie per averci accompagnato in questo. So che molte persone ne sono davvero entusiaste. Quindi, come possiamo impedire all'editore di utilizzare blocchi che non sono supportati?

BLAKE WILSON: Sì, sì. Quindi c'è un plugin là fuori. Dipende. Se stai utilizzando blocchi di terze parti, alcuni di questi hanno già questa funzione integrata.

Ma in caso contrario, c'è un plug-in là fuori chiamato visibilità del blocco, che puoi effettivamente attivare o disattivare blocchi specifici dal punto di vista dell'editore. Supponiamo quindi che tu abbia un blocco carosello che non è stato ancora implementato sul tuo sito Faust. Puoi installare la visibilità del blocco e deselezionarla in modo che l'editore non la utilizzi mentre è ancora non supportata o in fase di sviluppo.

TERESA GOBBLE: Oh, fantastico. In modo che la visibilità del blocco del plug-in possa effettivamente attivare, nascondere, mostrare blocchi specifici?

BLAKE WILSON: Sì, sì, esattamente. In questo modo, hai un numero limitato di blocchi che hai supportato, sia nel tuo lato WordPress che nel tuo sito headless in modo che gli editori sappiano, OK, possiamo usarlo con certezza che sarà supportato sul fine frontale.

TERESA GOBBLE: Oh, suona sicuramente come una consegna più pulita. Ok bello. Ultima domanda per te. Questi blocchi front-end corrispondono all'editor dell'editore?

BLAKE WILSON: Sì, grande callout. Quindi non ancora. Questo è qualcosa su cui lavoreremo in futuro, ma per ora questi blocchi sono supportati per il front-end headless.

Se hai un blocco personalizzato che hai creato in WordPress, se stai usando il comando NPX create block, dovrai comunque supportare quella vista sul lato WordPress. Ma è qualcosa su cui stiamo lavorando. Ce l'abbiamo nella nostra tabella di marcia.

TERESA GOBBLE: Oh, fantastico. OK. Grazie per aver parlato di questi punti con noi, Blake. È stato davvero utile, e anche la demo.

Andiamo avanti e cambiamo marcia e parliamo un po' di più della tabella di marcia del progetto. In realtà abbiamo cinque fasi, due delle quali sono già state completate: fase 1 e fase 2. Fase 1, abbiamo visto l'implementazione di un metodo per decostruire e quindi ricostruire un blocco in modo efficiente.

Successivamente, siamo passati alla fase 2, che si è concentrata su una più stretta integrazione di Faust con Gutenberg Blocks al fine di garantire che tutti abbiano accesso alle diverse utilità e funzioni di supporto presenti. Nella prossima fase in cui ci troviamo attualmente, la fase 3, ci stiamo concentrando sul fornire il supporto theme.json e librerie di blocchi riutilizzabili, come menzionato da Blake durante la nostra discussione tecnica.

Dopo averlo fatto, si verificheranno le fasi 4 e 5. La fase 4 si concentra sul miglioramento dell'esperienza di sviluppo e modifica esistente, così come la fase 5, che si concentra sul supporto dell'ecosistema più ampio oltre il core di WordPress. Siamo davvero entusiasti per queste fasi che stanno arrivando e speriamo che tocchi la base con noi e dai un'occhiata anche al nostro post sul blog per tenerti aggiornato su dove si trova la tabella di marcia.

Puoi vedere un link nella chat qui sotto ai nostri post sul blog se dai un'occhiata. Vai avanti e aggiungili ai segnalibri. Bene, grazie a tutti per esservi uniti alla nostra discussione per il ponte React-Gutenberg. Voglio riportare Blake sullo schermo qui in modo che anche lui possa ringraziare e darci qualche informazione in più su dove puoi andare se hai domande persistenti dopo questo.

BLAKE WILSON: Sì, grazie, Teresa, e grazie a tutti coloro che si sono uniti a questa sessione oggi e hanno guardato. Siamo davvero entusiasti di ricevere un feedback dalla community su questa funzione affinché tutti voi possiate iniziare a provarla.

Quindi, se ti piace, abbiamo il progetto di esempio nel link nella chat. Abbiamo anche un link nella chat per il nostro Headless Discord, quindi solo un posto in cui tu e altri sviluppatori headless che la pensano allo stesso modo potete unirvi e parlare delle funzionalità e delle versioni imminenti nello spazio headless. Quindi grazie ancora a tutti voi. Lo apprezziamo davvero.