DE{CODICE}: Gutenberg e WordPress senza testa

Gutenberg, noto anche come blocchi di WordPress, offre ai produttori di contenuti nuovi e potenti modi per disporre i contenuti in un sito WordPress tradizionale. Ma come possono gli sviluppatori headless di WordPress dotare i team di marketing di quelle stesse capacità? In questa sessione DE{CODE}, il fondatore di GraphQL per WordPress (WPGraphQL), Jason Bahl, condivide nuove funzionalità e best practice per l'utilizzo dell'editor a blocchi di WordPress su un sito headless.

Slide della sessione

Trascrizione del testo completo

JASON BAHL : Salve. Benvenuti al mio intervento su Gutenberg e Headless WordPress. Mi chiamo Jason Bahl. Sono il creatore e il manutentore di WPGraphQL. Sono un ingegnere informatico principale presso WP Engine. Puoi trovarmi su Twitter @jasonbahl o anche su Twitter @wpgraphql.

Quindi oggi voglio parlarti di cos'è Gutenberg, WordPress senza testa, quando e perché potresti voler usare WordPress senza testa, come puoi usare Gutenberg, in particolare, con WordPress senza testa e quando e perché WordPress senza testa e Gutenberg insieme potrebbero avere senso per i tuoi progetti.

Quindi WordPress storicamente ha avuto un editor che assomigliava un po' a questo. Abbiamo avuto un'area di testo TinyMCE, dove possiamo modificare il nostro contenuto. Possiamo inserire media e quindi pubblicare i nostri contenuti e poi nel 2018 è arrivato Gutenberg, questo editor basato su blocchi, che ci consente di inserire contenuti in questa tela bianca e interagire con i nostri contenuti a livello di blocco.

Quindi ogni paragrafo ha impostazioni. Ogni immagine ha impostazioni. Ogni galleria, intestazione: qualsiasi cosa tu possa pensare per il contenuto è ciò che viene chiamato il blocco. E possiamo diventare davvero granulari con il modo in cui controlliamo i nostri contenuti ora e possiamo trascinarli e rilasciarli e comporre i nostri contenuti. Quindi è questa esperienza di editing molto ricca in WordPress ora e quindi è un'introduzione a ciò che è Gutenberg.

Allora, cos'è Headless WordPress ora? Quindi, per capire Headless, diamo un'occhiata al WordPress tradizionale. Quindi WordPress tradizionale, accediamo a WordPress, l'interfaccia utente di amministrazione, e pubblichiamo i nostri contenuti e quindi gli utenti visitano il nostro sito e PHP, il linguaggio integrato in WordPress, esegue il rendering della pagina. Quindi carica CSS, HTML e JavaScript e consegna la pagina all'utente. Quindi è una specie di WordPress tradizionale.

Con Headless WordPress, usi ancora WordPress come CMS. Continuiamo a pubblicare contenuti, curare contenuti, amministrare contenuti in WordPress, ma invece di fornire una pagina in HTML al browser, WordPress fornisce dati in genere in formato JSON e quindi le applicazioni client possono consumare tali dati in modo da poter disporre di applicazioni iOS o Android native o anche applicazioni di realtà virtuale.

Il mio collega, Anthony, ha condiviso contenuti su come sta usando WordPress per potenziare le applicazioni di realtà virtuale. Oppure ho lavorato in un giornale in cui abbiamo utilizzato WordPress come punto di ingresso per i nostri giornali cartacei. Quindi, se stavi leggendo una copia cartacea di un giornale stampato, stavi leggendo un contenuto prodotto in WordPress.

E, naturalmente, possiamo ancora utilizzare quei dati anche per il rendering sul Web, ma invece di essere vincolati ai modelli PHP, abbiamo la flessibilità di scegliere qualsiasi tecnologia front-end desideriamo. Quindi Headless separa il back-end, la gestione dei contenuti e il modo in cui presentiamo i dati gestiti in WordPress.

Quindi ci sono due modi comuni in cui possiamo usare questi dati. Possiamo ottenere dati in formato JSON dall'API REST di WP, che è un'API integrata in WordPress e c'è un'altra API chiamata WPGraphQL. Questo è un plug-in open source che puoi installare e ottenere dati da WordPress e JSON. E oggi parleremo di WPGraphQL.

Quindi, ora che sappiamo cos'è WordPress, perché potresti creare progetti Headless WordPress? Come ho già detto, hai molta flessibilità nella scelta della tua tecnologia di front-end. E per alcune persone, è molto importante poter scegliere come costruire i progetti front-end. Ci sono alcuni framework come Next e Gatsby e Svelte che mirano davvero a migliorare i core web vitals. Quindi potresti essere in grado di andare senza testa con WordPress e migliorare i parametri vitali del web.

Puoi trarre vantaggio da cose come la suddivisione del codice nel tuo codice. Quindi puoi creare componenti per la tua applicazione front-end. E in base a quale componente viene creato per la pagina specifica, invierà risorse inferiori o inferiori al cliente e velocizzerà le tue pagine. Headless offre inoltre agli sviluppatori un controllo più preciso sull'esperienza utente front-end, quindi i plug-in installati nell'amministratore di WordPress hanno un impatto minore sul front-end

Quindi gli utenti amministratori non possono semplicemente installare plug-in e aggiungere script arbitrari o markup arbitrari al front-end di un sito Headless. È più uno sviluppatore che definisce i vincoli sul front-end e WordPress riceve i dati inviati e quindi una delle cose che voglio inserire è l'esperienza dello sviluppatore.

Con Headless WordPress, poiché hai la flessibilità di utilizzare qualsiasi stack tecnologico desideri, in alcuni casi c'è il vantaggio di una migliore esperienza di sviluppo. E uno di quei casi in cui entrerò si chiama sviluppo basato su componenti e ne parleremo molto tra un secondo.

Ecco alcuni dei motivi per cui. Quindi in quali situazioni potresti trovarti quando vuoi utilizzare Headless WordPress? Bene, se hai bisogno di creare applicazioni non web come i dispositivi mobili nativi, probabilmente vorrai andare su Headless. Ancora una volta, se i tuoi parametri vitali web principali sono scarsi sul tuo sito WordPress, sul tuo attuale sito WordPress o sono OK, ma sta diventando molto costoso mantenerli buoni, potresti prendere in considerazione Headless.

Se disponi di più applicazioni nella tua organizzazione che devono estrarre dati da WordPress, potresti dover passare anche a Headless. E se hai già investito in una libreria di componenti o in un sistema di progettazione basato su componenti per la tua organizzazione e hai bisogno di dati da WordPress, potresti voler investire in Headless. Se un team preferisce JavaScript e non ama costruire cose in PHP, anche questo è un motivo per considerare Headless.

Alcuni motivi per cui potresti non voler diventare Headless, tuttavia, al momento ci vuole un po' di tempo in più per lo sviluppo. Quindi, se hai un budget inferiore o riduci i tempi e disponi già di soluzioni in WordPress tradizionale, potresti non passare ancora a Headless. Se gli amministratori del tuo sito hanno davvero bisogno del controllo dell'installazione di plug-in che modificano il front-end, potresti non diventare ancora Headless.

Se il tuo team preferisce davvero PHP e non vuole imparare JavaScript o front-end alternativi, potresti restare anche con WordPress tradizionale. E se non sei investito in uno sviluppo basato su componenti o in una libreria basata su componenti, se non sei interessato a questo, potresti restare fedele ai tradizionali flussi di lavoro di sviluppo di WordPress.

E se i tuoi valori fondamentali per il web sul tuo WordPress tradizionale sono davvero buoni e i tuoi costi di manutenzione sono molto bassi per mantenere il tuo sito web molto veloce, potresti essere a posto con il WordPress tradizionale. Quindi non devi andare senza testa. Ma ti mostrerò perché penso che andare senza testa possa essere utile per alcune squadre.

Quindi, se guardiamo di nuovo all'esperienza degli sviluppatori di WordPress, pubblichiamo i nostri contenuti in un campo che genera una grossa fetta di HTML. E anche se usiamo l'editor Gutenberg, che ha questi blocchi granulari, il risultato finale è un grosso pezzo di HTML. E quindi, sia che pubblichiamo in Gutenberg o nel tradizionale editor classico, questo pezzo di HTML viene inviato tramite PHP al nostro tema e abbiamo una pagina globale che carica il nostro HTML, il nostro CSS e il nostro JavaScript. E queste risorse vengono applicate alla pagina a livello globale.

Quindi gli sviluppatori di WordPress in genere disaccoppiano il nostro sviluppo in base ai tipi di file, quindi inseriremo il nostro CSS in file separati che vengono applicati globalmente alla pagina, oppure l'HTML verrà scritto in PHP, estraendo i dati di cui abbiamo bisogno da WordPress e quindi JavaScript lo farà essere scritto spesso con jQuery in file separati. E così queste tre cose si uniranno per costruire la pagina.

Il problema è che questi non sono isolati, sono applicati all'intera pagina. Quindi a volte puoi fare un cambiamento. Come è successo a me. Una volta ho apportato una modifica a uno stile nel piè di pagina di un sito come richiesto dal mio manager e tre giorni dopo, è stato segnalato che lo stile in qualche altra parte del sito era cambiato a causa di quella revisione del codice di accesso. L'abbiamo superato.

All'improvviso, qualcos'altro sul sito è stato rotto e questo perché i CSS sono applicati a livello globale e potrebbero avere un impatto su cose di cui non ti rendi conto. C'è una nuova tendenza, però, negli ultimi sette, otto anni forse chiamata architettura basata su componenti. Questo ci consente di costruire parti specifiche della nostra applicazione in quelli che vengono chiamati componenti.

E possiamo accoppiare il nostro JavaScript, il nostro HTML, il nostro CSS in piccoli pezzi che possiamo testare isolatamente e quindi possiamo costruire parti della nostra applicazione. Un paio di preoccupazioni, il markup, i JavaScript, gli stili e possiamo comporre questi componenti insieme per creare applicazioni più complesse.

E così lo sviluppo basato su componenti ci consente di suddividere funzionalità complesse in parti isolate più piccole e possiamo testarle isolatamente, assicurarci che funzionino e quindi possiamo unire le nostre preoccupazioni che dovrebbero essere accoppiate. Ogni sezione dell'interfaccia utente ha una responsabilità specifica. Se si tratta di una scheda immagine, potrebbe essere responsabile del rendering dell'immagine a una determinata dimensione con un URL specifico.

Quindi ha dipendenze di markup. Ha dipendenze di stile. Potrebbe avere interazioni stateful. Questi sono tutti interessati a quel componente specifico. Quindi possiamo unire il nostro markup, il nostro JavaScript e il nostro CSS in un unico posto, testarlo e assicurarci che funzioni bene. E per questo motivo, possiamo quindi riutilizzare questi componenti in tutta la nostra applicazione, oppure possiamo persino riutilizzare i nostri componenti tra i progetti.

Quindi c'è una tendenza chiamata librerie di componenti. Ci sono progetti come l'interfaccia utente materiale, o componenti di design finale, o anche l'interfaccia utente Chakra è popolare. E possiamo utilizzare questi componenti in tutti i progetti. E possiamo risolvere problemi centrali come il markup accessibile. E possiamo aggiornarli e applicarli a più progetti contemporaneamente nella nostra organizzazione e per questo motivo, per questi motivi, possiamo iterare e spedire più velocemente spesso con molta più sicurezza.

Quindi, come possiamo usare Headless WordPress allora? Come ho detto prima, ci sono due modi per estrarre i dati da WordPress e inserirli nei componenti. Uno sarebbe l'API REST. Uno sarebbe WPGraphQL. Il mio amico, Drake, costruisce siti Headless da un po', quindi gliel'ho chiesto e questo è quello che ha detto...

Preferisce WPGraphQL. Quindi è di questo che parleremo oggi. Quindi cos'è WPGraphQL? Potresti chiedere. Bene, è un plug-in WordPress open source gratuito che fornisce uno schema e un'API GraphQL estensibili per qualsiasi sito WordPress. Cos'è allora GraphQL? Bene, è un linguaggio di query grafico.

Va bene, Jason. Continuo a non capire cosa stai dicendo. Va bene, quindi lascia che te lo mostri. Quindi GraphQL, il modo in cui funziona è che le applicazioni client inviano una richiesta specificando cosa vogliono dal server. E una richiesta è simile a questa. Sembra chiavi JSON senza valori. Quindi, in questo caso, la richiesta richiede il visualizzatore e su un visualizzatore vogliamo che venga restituito il campo "nome".

E una risposta dal server GraphQL potrebbe essere simile a questa. I suoi dati, chiavi e valori JSON effettivi e corrisponde alla forma della richiesta. Quindi, in questo caso, otteniamo il nome o otteniamo lo spettatore con il nome Jason Bahl. Quindi GraphQL consente alle applicazioni client di estrarre gli alberi dal grafico dei dati dell'applicazione.

E quello che sembra visivamente è qualcosa del genere. Possiamo entrare nel grafico, diciamo, aggiungere un visualizzatore o un campo utente o un nodo. E quel nodo potrebbe avere una proprietà come un nome Jason. E quel nodo potrebbe avere connessioni ad altri nodi nel grafico come un avatar, che potrebbe avere una proprietà come l'URL di un'immagine.

E quell'utente potrebbe avere connessioni ad altri nodi come post che quell'utente ha creato. E quei post potrebbero avere proprietà stesse come un titolo, ciao mondo o arrivederci Marte. E questi post potrebbero avere collegamenti ad altri nodi nel grafico, come categorie con i propri titoli come notizie o sport. E quelle categorie potrebbero avere connessioni anche ad altri nodi come più post. E quei post potrebbero contenere immagini e così via. Quindi abbiamo questo grande grafico di dati di cui possiamo chiedere pezzi con GraphQL.

E così possiamo usare gli strumenti nell'amministratore di GraphQL o nell'amministratore di WordPress. C'è uno strumento chiamato GraphiQL, dove posso comporre una query. E qui seleziono il campo Viewer con sottoselezioni, nome, avatar, l'URL e quando lo eseguiamo, otteniamo i campi che chiediamo e quindi visivamente quella query assomiglia un po' a questa.

Siamo entrati nel grafico e abbiamo chiesto un utente. Abbiamo chiesto il nome dell'utente, l'avatar connesso nell'URL dell'avatar. Abbiamo tutto questo grafico di dati a nostra disposizione, ma chiediamo solo un insieme specifico di dati e, in risposta, otteniamo quello specifico set indietro. E quindi possiamo prendere --- ora possiamo usare i componenti.

Quindi ho parlato dei vantaggi dello sviluppo basato su componenti e voglio mostrartelo in azione. E quindi questo è ciò che definirei un componente di presentazione. Quindi questo è un componente della carta che è responsabile. Ha una responsabilità nel rendere questa carta con un'immagine e un titolo.

E possiamo guardare il codice e vedere che abbiamo un certo controllo dello stile. Possiamo impostare la larghezza, possiamo passargli l'immagine che vogliamo e possiamo passargli il titolo. Quindi possiamo riutilizzare questo componente in tutto il nostro progetto. E questo componente ha tutte le dipendenze di cui abbiamo bisogno. Ha l'HTML da rendere. Ha gli stili. Abbiamo un certo controllo dello stile qui. Ha alcuni componenti stateful come lo stato hover e quant'altro.

Quindi questo è un componente isolato che possiamo riutilizzare e con GraphQL ora, possiamo prendere la query che abbiamo appena composto nell'amministratore di WordPress usando GraphQL e possiamo introdurla e avere ora un componente della scheda visualizzatore. Quindi possiamo scrivere la nostra query, accoppiarla con il nostro componente card e ora completa il componente.

Abbiamo il nostro HTML, CSS il nostro JavaScript. E grazie ai dati, ora abbiamo qualcosa da rendere con i dati che abbiamo richiesto. Quindi ora possiamo usarlo in tutta la nostra applicazione e c'è una funzionalità di GraphQL chiamata frammenti e questo ci consente di prendere le nostre query GraphQL e suddividerle in pezzi riutilizzabili.

Quindi, in questo caso, sto creando un frammento di scheda del profilo utente e sto specificando nome, avatar e URL e poi sto usando quel frammento in una query più grande. Quando eseguiamo, otteniamo i risultati che ci aspettiamo. Ora possiamo prendere quel frammento, inserirlo in un componente. Ora abbiamo un componente diverso chiamato Scheda profilo utente.

Questa scheda del profilo utente specifica che ogni volta che interroghiamo un utente, dovremmo ottenere il nome, l'avatar e l'URL dell'avatar da utilizzare nel componente. Quindi ora abbiamo questo componente riutilizzabile che ovunque nella nostra applicazione chiediamo per un utente, possiamo ottenere i dati necessari per rendere questa carta riutilizzabile con l'avatar e il nome dell'utente.

E quindi questo ora può essere introdotto e utilizzato in parti più grandi della nostra applicazione. Quindi ecco la query che avevamo prima della query del visualizzatore utilizzando il frammento che stiamo importando da un componente della scheda del profilo utente riutilizzabile. E poi lo stiamo emettendo in un componente della scheda visualizzatore e ora possiamo riutilizzarlo nella nostra applicazione.

Possiamo realizzare parti più grandi della nostra applicazione che si basano su questa scheda utente o sulla scheda autore. Quindi ora possiamo avere più componenti come il componente del titolo del blog che è responsabile del titolo. Possiamo avere una scheda del profilo utente che abbiamo appena creato che rende il profilo dell'utente. Possiamo avere un componente di contenuto o estratto responsabile del markup e dei dati per questa parte della nostra applicazione.

E sì, possiamo creare questi piccoli componenti responsabili del markup, del CSS e dei dati necessari per creare questa applicazione. E possiamo comporli insieme. Possiamo testarli isolatamente, testarli anche come unità più grandi. Quindi possiamo usarlo anche in vari modelli.

Possiamo utilizzare questi componenti riutilizzabili per un post sul blog o per il nostro ruolo del blog in cui abbiamo autori diversi, ma possiamo utilizzare lo stesso componente per renderli. Possiamo usarlo per– l'altra pagina di archivio. In modo molto simile alle parti del modello di WordPress, possiamo suddividere le nostre applicazioni Headless in piccoli pezzi, ma otteniamo il vantaggio di unire la nostra tecnologia.

Quindi si tratta un po' dello sviluppatore di WordPress senza testa che sperimenta la progettazione basata su componenti e i vantaggi che ne derivano. Quindi ora, quando si tratta di Gutenberg, in particolare, perché dovresti considerare Headless WordPress con Gutenberg in particolare? Bene, se il tuo team sta già utilizzando Headless WordPress, possibilmente con campi personalizzati avanzati e flexfield, e desideri aggiornare l'esperienza dell'editor per utilizzare Gutenberg, questo è ovviamente uno dei motivi per cui potresti passare a Headless con Gutenberg.

Se vuoi trarre vantaggio dalla creazione di componenti utilizzati nell'amministratore e componenti utilizzati nel front-end, è un buon motivo per considerare di andare senza testa con Gutenberg perché l'editor di back-end Gutenberg dell'editor di blocchi è tutto basato sui componenti. Potresti voler sfruttare l'input strutturato. ogni blocco nell'amministratore ha campi strutturati.

Hai attributi specifici che puoi controllare a livello di campo. E potresti trarre vantaggio dal fatto che quell'output strutturato arrivi anche ai tuoi componenti. E come ho detto, potresti voler riutilizzare componenti e blocchi tra i progetti. Ad esempio, potresti voler disporre di una libreria di blocchi creata dalla tua agenzia che risolva problemi come l'accessibilità e specifici problemi di markup che desideri utilizzare nei progetti. E poi puoi aggiornarli nei tuoi progetti, non solo all'interno di un singolo progetto.

Quindi questa è una parte in cui come i temi figlio in WordPress possono essere difficili da ridimensionare perché devi andare su ogni singolo sito e aggiornare il markup e quant'altro su ogni singolo sito. Bene, qui puoi utilizzare le librerie di blocchi come dipendenze NPM e aggiornarle in tutta la tua organizzazione.

Quindi attualmente, lo stato dello sviluppo di WordPress con Gutenberg è che abbiamo blocchi sul back-end, che sono basati su componenti. Possiamo creare i nostri blocchi personalizzati o utilizzare i blocchi principali di WordPress. Ma l'output in PHP è, come ho già detto, quel grosso pezzo di HTML e quindi come possiamo passare dall'ottenere questo blocco di HTML ad avere componenti sul back-end che si trasferiscono anche ai componenti sul nostro front-end?

Quindi esamineremo alcune opzioni per estrarre i dati di Gutenberg da WordPress e inserirli nei componenti. Quindi un'opzione è ottenere il contenuto come HTML. Quindi possiamo interrogare il nostro contenuto WordPress come HTML e quindi analizzare quell'HTML in componenti. Oppure possiamo interrogare i blocchi come tipi GraphQL. Quindi possiamo– che ci consente di interrogare un elenco di blocchi, ogni blocco sarebbe un tipo GraphQL che possiamo mappare a un componente.

Quindi il contenuto è HTML. Questo è qualcosa che possiamo fare oggi nel core di WPGraphQL. Se vuoi interrogare i blocchi come singoli tipi GraphQL, al momento ci sono due opzioni. Abbiamo GraphQL per l'estensione Gutenberg, che è un'estensione della community e poi abbiamo WPGraphQL Block Editor, che è un plug-in beta su cui sto lavorando personalmente.

E quindi diamo un'occhiata a queste opzioni. Nel core di WPGraphQL, possiamo interrogare il contenuto come HTML e analizzare i componenti. Quello che sembra è che interroghiamo qualcosa come un post e possiamo chiedere campi come ID e titolo o contenuto. E il contenuto restituirà una grande stringa, un grosso pezzo di HTML e quindi possiamo analizzare quell'HTML e mappare diversi nodi DOM a diversi componenti.

Come in questo caso su wpgraphql.com, il collegamento in alto a sinistra è al codice in cui ciò sta effettivamente accadendo. Prendo il markup restituito da WPGraphQL e lo analizzo, cerco nodi HTML specifici e lo converto in componenti React. Quindi posso avere cose interattive come questo blocco di codice, che evidenzia la sintassi e consente agli utenti di fare clic su Copia e poi posso anche analizzare e creare un sommario, per esempio. Quindi questo è un approccio. E lo sto usando in wpgraphql.com in produzione oggi.

Alcune cose che potresti prendere in considerazione se segui questa strada, i payload HTML possono essere imprevedibili. Modifiche nel server come l'installazione di una nuova libreria di blocchi o vari HTML che gli editor possono inserire nel contenuto, sono imprevedibili. Quindi potrebbe essere molto difficile da analizzare. Non puoi osservare i cambiamenti. Come sviluppatore client, non puoi vedere cosa è cambiato, quindi solo qualcosa da considerare.

Direi che questo approccio funziona meglio per i team che hanno un controllo molto stretto sull'amministratore di WordPress e sul front-end. Quindi, se sei una singola persona o un piccolo team che lavora sul backend e sul front-end di WordPress, potrebbe funzionare bene per te perché puoi controllare un po' meglio l'input e l'output.

Una delle altre opzioni, WPGraphQL per Gutenberg, è un plugin gestito dalla comunità. E questo ti consentirà di interrogare i blocchi di contenuto, ogni blocco come il proprio tipo GraphQL. Il modo in cui funziona è una pagina delle impostazioni, devi inserire solo i blocchi come schema, quindi questo apre Gutenberg in un iframe invisibile, ottiene il registro dei blocchi dal client JavaScript e lo invia al server.

E poi possiamo usare GraphQL per interrogare i nostri blocchi come tipi specifici, e possiamo usare frammenti come ho mostrato prima e possiamo usare questi frammenti per mappare i componenti sul nostro front-end. Quindi questa è un'opzione. Alcune considerazioni con questo plugin, le modifiche al registro dei blocchi sono introspettibili, quindi è una buona cosa.

I team che lavorano sull'applicazione front-end possono utilizzare l'introspezione di GraphQL per vedere come lo schema cambia nel tempo e possono sapere se ci sono modifiche sostanziali o nuovi campi che possono utilizzare. Direi che questo approccio funziona un po' meglio per progetti con più persone o con più team. Se hai un team che lavora sull'amministratore di WordPress e un altro team che lavora sul front-end, questo approccio potrebbe funzionare meglio. Possono utilizzare lo schema GraphQL come contratto tra i blocchi utilizzati su entrambi i lati.

Una cosa un po' interessante è che carica i blocchi nell'iframe come ho detto. E per questo motivo, non sempre si adatta a ogni situazione. Quindi, se registri blocchi su una pagina specifica o un modello specifico o un tipo di post specifico, questo metodo per ottenere la mappa del registro dei blocchi sullo schema potrebbe perdere alcuni blocchi. Quindi potrebbe non essere scalabile per ogni progetto.

Quindi il prossimo progetto, WPGraphQL Block Editor, questo è un plugin beta su cui sto lavorando attualmente. E questo ti consente anche di interrogare i blocchi di contenuto come il loro tipo GraphQL e quindi molto simile a WPGraphQL per Gutenberg, possiamo scrivere frammenti che restituiscono i dati che specifichiamo. E poi possiamo usare quei frammenti con i nostri componenti sul front-end.

Alcune considerazioni con questo, è un plugin beta, quindi c'è quello. Trai vantaggio dall'input strutturato e dall'output strutturato. Quindi, come sviluppatore front-end, questa è sicuramente una vittoria. Funziona con i blocchi registrati con il file block.json. Quindi i blocchi principali di WordPress Gutenberg hanno questo file e quindi funzionerà con quell'approccio. Molte terze parti non registrano i loro blocchi in questo modo, quindi dovresti mappare manualmente quei blocchi.

I blocchi non sono trattati come singoli nodi. Vorrei trattare i blocchi come singoli nodi, ma non esiste un ID globale, quindi devi accedere a quei blocchi come parti di oggetti più grandi come una pagina poster.

Quindi spero che tu abbia imparato qualcosa su Headless WordPress, sui vantaggi di Headless WordPress e sull'utilizzo di Headless WordPress con Gutenberg. Ti invito a provare WPGraphQL oggi. Puoi registrarti per un account Atlas Sandbox gratuito su wpengine.com/atlas. E grazie per esserti unito alla mia presentazione. Di nuovo, puoi trovarmi su Twitter, jasonbahl o anche su Twitter @wpgraphql. Grazie.