DE{CODE}: Gutenberg și WordPress fără cap

Gutenberg, alias WordPress blocks, oferă producătorilor de conținut noi moduri puternice de a așeza conținutul într-un site WordPress tradițional. Dar cum pot dezvoltatorii WordPress fără cap să împuternicească echipele de marketing cu aceleași capacități? În această sesiune DE{CODE}, fondatorul GraphQL pentru WordPress (WPGraphQL), Jason Bahl, împărtășește noi capabilități și cele mai bune practici pentru utilizarea editorului de blocuri WordPress pe un site fără cap.

Diapozitive de sesiune

Transcriere text integral

JASON BAHL : Bună. Bun venit la discursul meu despre Gutenberg și WordPress Headless. Numele meu este Jason Bahl. Sunt creatorul și menținătorul WPGraphQL. Sunt inginer principal de software la WP Engine. Mă puteți găsi pe Twitter @jasonbahl sau și pe Twitter @wpgraphql.

Așadar, astăzi, vreau să vă vorbesc despre ce este Gutenberg, WordPress fără cap, când și de ce ați putea dori să utilizați WordPress Headless, cum puteți folosi Gutenberg, în special, cu WordPress Headless și când și de ce WordPress și Gutenberg Headless împreună ar putea avea sens pentru proiectele dvs.

Deci, WordPress a avut din punct de vedere istoric un editor care arăta puțin așa. Am avut o zonă de text TinyMCE, unde ne putem edita conținutul. Putem insera media și apoi să ne publicăm conținutul, iar apoi în 2018 a apărut Gutenberg, acest editor bazat pe blocuri, care ne permite să inserăm conținut în această pânză goală și să interacționăm cu conținutul nostru la nivel de bloc.

Deci, fiecare paragraf are setări. Fiecare imagine are setări. Fiecare galerie, titlu – orice vă puteți gândi pentru conținut este ceea ce se numește blocul. Și putem deveni foarte detaliați cu modul în care ne controlăm conținutul acum și îl putem trage și plasa și să ne compunem conținutul. Deci, este această experiență de editare foarte bogată în WordPress acum și deci este o notă despre ce este Gutenberg.

Deci, ce este Headless WordPress acum? Deci, pentru a înțelege Headless, să ne uităm la WordPress tradițional. Așadar, WordPress tradițional, ne conectăm la WordPress, interfața de utilizare admin, și ne publicăm conținutul, apoi utilizatorii ne vizitează site-ul, iar PHP, limbajul în care WordPress a construit, redă pagina. Deci, încarcă CSS, HTML și JavaScript și oferă pagina utilizatorului. Deci, acesta este un fel de WordPress tradițional.

Cu WordPress Headless, încă folosiți WordPress ca CMS. Încă publicați conținut, gestionați conținut, administrați conținut în WordPress, dar în loc să livrați o pagină în HTML către browser, WordPress furnizează date de obicei în format JSON, iar apoi aplicațiile client pot consuma acele date, astfel încât să putem avea aplicații native iOS sau Android sau chiar aplicații de realitate virtuală.

Colegul meu, Anthony, a împărtășit conținut despre cum folosește WordPress pentru a alimenta aplicațiile de realitate virtuală. Sau am lucrat la un ziar unde am folosit WordPress ca punct de intrare pentru ziarele noastre tipărite. Deci, dacă ați citit o copie tipărită a unui ziar tipărit, ați citit conținut produs în WordPress.

Și, desigur, putem folosi în continuare acele date și pentru a reda pe web, dar în loc să fim blocați pentru șabloane PHP, avem flexibilitate de a alege orice tehnologie front-end ne dorim. Deci Headless decuplează back-end-ul, gestionarea conținutului și modul în care prezentăm datele care sunt gestionate în WordPress.

Deci, există două moduri comune în care putem folosi aceste date. Putem obține date în format JSON din API-ul WP REST, care este un API încorporat în WordPress și există un alt API numit WPGraphQL. Acesta este un plugin open-source pe care îl puteți instala și obține date din WordPress și JSON. Și vom vorbi despre WPGraphQL astăzi.

Deci, acum că știm ce este WordPress, de ce ai putea să te duci să construiești proiecte Headless WordPress? După cum am menționat, aveți multă flexibilitate în alegerea tehnologiei front-end. Și pentru unii oameni, acesta este un lucru foarte important să poată alege cum construiesc proiectele front-end. Există unele cadre precum Next și Gatsby și Svelte care vizează cu adevărat elementele vitale web de bază îmbunătățite. Așa că s-ar putea să reușiți să treceți fără cap cu WordPress și să aveți elemente vitale web de bază îmbunătățite.

Puteți beneficia de lucruri precum împărțirea codului în codul dvs. Astfel, puteți construi componente pentru aplicația dumneavoastră front-end. Și în funcție de ce componentă este construită pentru pagina specifică, va trimite mai puține sau mai puține active clientului și va accelera paginile. Headless oferă dezvoltatorilor un control mai fin asupra experienței utilizatorului front-end, astfel încât pluginurile care sunt instalate în administratorul WordPress au un impact mai mic asupra front-end-ului.

Deci, utilizatorii admin nu pot să instaleze pluginuri și să aibă scripturi arbitrare sau markup arbitrare adăugate la front-end-ul unui site Headless. Mai degrabă un dezvoltator definește constrângerile pe front-end și WordPress primește datele trimise și apoi unul dintre lucrurile pe care vreau să le introduc este experiența dezvoltatorului.

Cu WordPress Headless, deoarece aveți flexibilitatea de a utiliza orice stivă tehnologică doriți, există un avantaj al experienței mai bune pentru dezvoltatori în unele cazuri. Și unul dintre acele cazuri în care voi intra se numește dezvoltare bazată pe componente și vom vorbi multe despre asta într-o secundă.

Deci, acestea sunt câteva motive. Așadar, în ce situații ai putea fi când vrei să folosești WordPress Headless? Ei bine, dacă trebuie să construiți aplicații non-web, cum ar fi mobilul nativ, probabil că doriți să mergeți la Headless. Din nou, dacă elementele vitale de bază ale dvs. web sunt slabe pe site-ul dvs. WordPress, pe site-ul dvs. WordPress actual sau sunt în regulă, dar devine foarte costisitor să le mențineți bune, vă recomandăm să luați în considerare Headless.

Dacă aveți mai multe aplicații în organizația dvs. care trebuie să obțină date din WordPress, s-ar putea să fie nevoie să mergeți și fără Headless. Și dacă sunteți deja investit într-o bibliotecă de componente sau într-un sistem de design bazat pe componente pentru organizația dvs. și aveți nevoie de date de la WordPress, s-ar putea să doriți să investiți în devenirea Headless. Dacă o echipă preferă JavaScript și nu-i place să construiască lucruri în PHP, acesta este, de asemenea, un motiv pentru a lua în considerare Headless.

Câteva motive pentru care s-ar putea să nu vrei să fii Headless – în prezent, este nevoie de puțin timp de dezvoltare în plus. Deci, dacă aveți un buget mai mic sau reduceți timpul și aveți deja soluții în WordPress tradițional, este posibil să nu treceți încă fără Headless. Dacă administratorii site-ului dvs. chiar au nevoie de control asupra instalării pluginurilor care modifică front-end-ul, este posibil să nu treceți încă fără Headless.

Dacă echipa dvs. preferă cu adevărat PHP și nu dorește să învețe JavaScript sau front-end-uri alternative, s-ar putea să rămâneți și cu WordPress tradițional. Și dacă nu sunteți investit într-o dezvoltare bazată pe componente sau într-o bibliotecă bazată pe componente, dacă nu aveți niciun interes în asta, s-ar putea să rămâneți cu fluxurile de lucru tradiționale de dezvoltare WordPress.

Și dacă elementele vitale web de bază pe WordPress-ul tău tradițional sunt cu adevărat bune, iar costurile de întreținere sunt foarte mici pentru a menține site-ul să funcționeze foarte repede, s-ar putea să fii în regulă să rămâneți cu WordPress tradițional. Deci nu trebuie să fii fără cap. Dar am să vă arăt de ce cred că a merge fără cap poate fi bun pentru unele echipe.

Deci, dacă ne uităm din nou la experiența dezvoltatorului WordPress, publicăm conținutul nostru într-un câmp care generează o mare parte de HTML. Și chiar dacă folosim editorul Gutenberg, care are aceste blocuri granulare, rezultatul final este o bucată mare de HTML. Deci, indiferent dacă publicăm în Gutenberg sau în editorul clasic tradițional, această bucată de HTML este trimisă prin PHP către tema noastră și avem o pagină globală care ne încarcă HTML, CSS și JavaScript. Și aceste elemente sunt aplicate paginii la nivel global.

Deci, dezvoltatorii WordPress vor decupla de obicei dezvoltarea noastră în funcție de tipurile de fișiere, așa că vom pune CSS-ul nostru în fișiere separate care sunt aplicate la nivel global pe pagină, sau HTML va fi scris în PHP și extragerea datelor de care avem nevoie din WordPress și apoi JavaScript va fi fi scris de multe ori cu jQuery în fișiere separate. Și astfel aceste trei lucruri se vor reuni pentru a construi pagina.

Problema este că acestea nu sunt izolate, ci sunt aplicate întregii pagini. Așa că uneori poți face o schimbare. Parcă mi s-a întâmplat asta. O dată am făcut o modificare a unui stil în subsolul unui site, așa cum mi-a cerut managerul meu și trei zile mai târziu, s-a raportat că stilul altundeva pe site s-a schimbat din cauza revizuirii codului de acces. L-am trecut.

Dintr-o dată, altceva de pe site s-a stricat și asta pentru că CSS este aplicat la nivel global și ar putea afecta lucruri de care nu îți dai seama. Există o nouă tendință, totuși, în trecut – nu știu – șapte, opt ani, poate numită arhitectură bazată pe componente. Acest lucru ne permite să construim piese specifice ale aplicației noastre în ceea ce se numește componente.

Și putem cupla JavaScript-ul nostru, HTML-ul nostru, CSS-ul nostru în bucăți mici pe care le putem testa izolat și astfel putem construi părți din aplicația noastră. Câteva preocupări, marcajul, JavaScript-urile, stilurile și putem compune aceste componente împreună pentru a construi aplicații mai complexe.

Și astfel, dezvoltarea bazată pe componente ne permite să împărțim caracteristicile complexe în bucăți mai mici izolate și le putem testa izolat, să ne asigurăm că funcționează și apoi ne putem cupla preocupările care ar trebui să fie cuplate. Fiecare porțiune de UI are o responsabilitate specifică. Dacă este un card de imagine, acesta ar putea fi responsabil pentru redarea imaginii la o anumită dimensiune cu o anumită adresă URL.

Deci are dependențe de markup. Are dependențe de stil. Ar putea avea interacțiuni cu stare. Toate acestea sunt preocupate de acea componentă specifică. Astfel, putem cupla marcajul, JavaScript și CSS într-un singur loc, îl putem testa și ne asigurăm că funcționează bine. Și din această cauză, putem apoi reutiliza aceste componente în aplicația noastră sau chiar putem reutiliza componentele noastre în cadrul proiectelor.

Deci există o tendință numită biblioteci de componente. Există proiecte precum Material UI sau componente de design final sau Chakra UI este, de asemenea, una populară. Și putem folosi aceste componente în cadrul proiectelor. Și putem rezolva probleme centrale, cum ar fi markup accesibil. Și le putem face actualizări și le putem aplica în mai multe proiecte din organizația noastră simultan și din acest motiv – din aceste motive, putem repeta și livra mai repede, adesea, cu mult mai multă încredere.

Deci, cum putem folosi WordPress Headless atunci? După cum am menționat mai devreme, există două moduri de a obține date din WordPress și în componente. Unul ar fi API-ul REST. Unul ar fi WPGraphQL. Prietenul meu, Drake, a construit site-uri Headless de ceva vreme, așa că l-am întrebat și asta a spus...

Preferă WPGraphQL. Deci despre asta vom vorbi astăzi. Deci, ce este WPGraphQL? S-ar putea să întrebi. Ei bine, este un plugin gratuit WordPress open-source care oferă o schemă GraphQL extensibilă și API pentru orice site WordPress. Ce este atunci GraphQL? Ei bine, este un limbaj de interogare grafic.

În regulă, Jason. Încă nu înțeleg ce spui. În regulă, lasă-mă să-ți arăt. Deci GraphQL, modul în care funcționează este că aplicațiile client trimit o solicitare specificând ceea ce doresc de la server. Și o cerere arată cam așa. Pare chei JSON fără valori. Deci, în acest caz, cererea solicită vizualizatorul și pe un vizualizator, vrem să fie returnat câmpul „nume”.

Și un răspuns de la serverul GraphQL ar putea arăta așa. Datele, cheile și valorile sale reale JSON și se potrivesc cu forma solicitării. Deci, în acest caz, obținem numele sau primim spectatorul cu numele Jason Bahl. Așadar, GraphQL să lăsăm aplicațiile client să scoată copaci din graficul datelor aplicației.

Și ceea ce arată vizual este ceva de genul acesta. Putem intra în grafic, să spunem, să adăugăm un vizualizator sau un câmp de utilizator sau un nod. Și acel nod ar putea avea o proprietate ca un nume Jason. Și acel nod ar putea avea conexiuni la alte noduri din grafic, cum ar fi un avatar, care ar putea avea o proprietate precum o adresă URL a imaginii.

Și acel utilizator ar putea avea conexiuni la alte noduri, cum ar fi postarea pe care utilizatorul a creat-o. Și aceste postări ar putea avea proprietăți, cum ar fi un titlu, salut lume sau la revedere Marte. Și aceste postări pot avea conexiuni cu alte noduri din grafic, cum ar fi categorii cu propriile titluri, cum ar fi știri sau sport. Și acele categorii ar putea avea conexiuni cu alte noduri, precum și mai multe postări. Și acele postări ar fi putut prezenta imagini și așa mai departe. Deci avem acest grafic mare de date pe care le putem cere bucăți cu GraphQL.

Și astfel putem folosi instrumente în administratorul GraphQL sau în administratorul WordPress. Există un instrument numit GraphiQL, unde pot compune o interogare. Și aici selectez câmpul Vizualizator cu subselecții, nume, avatar, adresa URL și când executăm asta, primim câmpurile pe care le solicităm și astfel vizual interogarea arată cam așa.

Am intrat în grafic și am cerut un utilizator. Am cerut numele utilizatorului, avatarul conectat în adresa URL a avatarului. Avem la dispoziție toate aceste grafice de date, dar cerem doar un anumit set de date și, ca răspuns, am primit acel set exact înapoi. Și atunci putem lua – acum putem folosi componente.

Așa că am vorbit despre beneficiile dezvoltării bazate pe componente și vreau să vă arăt acest lucru în acțiune. Și asta este ceea ce aș numi o componentă de prezentare. Deci aceasta este o componentă a cardului care este responsabilă. Are o singură responsabilitate pentru redarea acestui card cu o imagine și un titlu.

Și ne putem uita la cod și vedem că avem un control al stilului. Putem seta lățimea, îi putem trece imaginea pe care o dorim și îi putem trece titlul. Astfel, putem reutiliza această componentă pe tot parcursul proiectului nostru. Și această componentă are toate dependențele de care avem nevoie. Are HTML pentru a reda. Are stilurile. Avem un control al stilului aici. Are câteva componente cu stare, cum ar fi starea hover și altele.

Deci, aceasta este o componentă izolată pe care o putem reutiliza și cu GraphQL acum, putem prelua interogarea pe care tocmai am compus-o în administratorul WordPress folosind GraphQL și o putem aduce și să avem o componentă de card de vizualizare acum. Deci putem scrie interogarea noastră, o cuplăm cu componenta cardului și acum completează componenta.

Avem HTML, CSS JavaScript. Și din cauza datelor, acum avem ceva de redat cu datele pe care le-am cerut. Așa că acum putem folosi acest lucru în aplicația noastră și există o caracteristică a GraphQL numită fragmente și aceasta ne permite să luăm interogările noastre GraphQL și să le împărțim în bucăți reutilizabile.

Deci, în acest caz, creez un fragment de card de profil de utilizator și specific numele, avatarul și adresa URL și apoi folosesc acel fragment într-o interogare mai mare. Când executăm, obținem rezultatele pe care le așteptăm. Acum putem lua acel fragment, îl punem într-o componentă. Acum avem o componentă diferită numită Card de profil utilizator.

Acest card de profil de utilizator specifică că de fiecare dată când interogăm un utilizator, ar trebui să obținem numele, avatarul și adresa URL a avatarului de utilizat în componentă. Deci acum avem această componentă reutilizabilă pe care oriunde în aplicația noastră cerem un utilizator, putem obține datele necesare pentru a reda acest card reutilizabil cu avatarul și numele utilizatorului.

Și astfel, acest lucru poate fi acum introdus și utilizat în părți mai mari ale aplicației noastre. Deci, iată interogarea pe care am avut-o înainte de interogarea vizualizatorului folosind fragmentul pe care îl importăm dintr-o componentă reutilizabilă a cardului de profil de utilizator. Și apoi îl trimitem într-o componentă a cardului de vizualizare și acum îl putem reutiliza în aplicația noastră.

Putem realiza părți mai mari ale aplicației noastre care se bazează pe acest card de utilizator sau pe cardul de autor. Deci, acum putem avea mai multe componente, cum ar fi componenta titlului blogului, care este responsabilă pentru titlu. Putem avea un card de profil de utilizator pe care tocmai l-am creat, care redă profilul utilizatorului. Putem avea o componentă de conținut sau extras care este responsabilă pentru marcarea și datele pentru această parte a aplicației noastre.

Și da, putem construi aceste componente mici care sunt responsabile pentru marcaj, CSS și datele necesare pentru a construi această aplicație. Și le putem compune împreună. Le putem testa izolat, le putem testa și ca unități mai mari. Deci îl putem folosi și în diferite șabloane.

Putem folosi aceste componente reutilizabile pentru o postare de blog sau pentru rolul nostru de blog în care avem autori diferiți, dar putem folosi aceeași componentă pentru a le reda. Îl putem folosi pentru – cealaltă pagină de arhivă. Așadar, foarte asemănător cu părțile șablonului WordPress, putem împărți aplicațiile noastre Headless în bucăți mici, dar obținem beneficiul de a cupla tehnologia noastră.

Deci, acesta este un pic despre dezvoltatorul Headless WordPress care experimentează un design bazat pe componente și beneficiile acestuia. Deci, acum, când vine vorba de Gutenberg, în special, de ce ați lua în considerare WordPress Headless cu Gutenberg în mod specific? Ei bine, dacă echipa dvs. folosește deja WordPress Headless, eventual cu câmpuri personalizate avansate și câmpuri flexibile, și doriți să actualizați experiența editorului pentru a utiliza Gutenberg, acesta este, evident, unul dintre motivele pentru care ați putea alege Headless cu Gutenberg.

Dacă doriți să beneficiați de componentele de construcție care sunt utilizate în administrare și componentele care sunt utilizate în front-end, este un motiv bun să luați în considerare utilizarea Headless cu Gutenberg, deoarece editorul de back-end Gutenberg al editorului de blocuri este bazat pe componente. Poate doriți să profitați de intrarea structurată. fiecare bloc din admin are câmpuri care sunt structurate.

Aveți atribute specifice pe care le puteți controla la nivel de câmp. Și s-ar putea să doriți să beneficiați de faptul că acea ieșire structurată va ajunge și la componentele dvs. Și, așa cum am menționat, s-ar putea să doriți să reutilizați componente și blocuri în cadrul proiectelor. De exemplu, s-ar putea să doriți să aveți o bibliotecă de blocuri pe care agenția dvs. a construit-o, care rezolvă lucruri precum accesibilitatea și problemele specifice de marcare pe care doriți să le utilizați în cadrul proiectelor. Și apoi le puteți actualiza pe toate proiectele dvs., nu doar în cadrul unui proiect individual.

Deci, aceasta este o parte în care temele similare copiilor din WordPress pot fi dificil de scalat, deoarece trebuie să accesați fiecare site și să actualizați marcajul și altele pe fiecare site. Ei bine, aici, puteți utiliza biblioteci bloc ca dependențe NPM și le puteți actualiza în organizația dvs.

Deci, în prezent, starea dezvoltării WordPress cu Gutenberg este că avem blocuri pe backend, care sunt bazate pe componente. Ne putem construi propriile blocuri personalizate sau putem folosi blocuri WordPress de bază. Dar rezultatul în PHP este, așa cum am menționat, acea bucată mare de HTML și, deci, cum putem trece de la obținerea acestui bloc de HTML la a avea componente pe backend care se transferă și la componente pe front-end-ul nostru?

Așa că vom analiza câteva opțiuni pentru a scoate datele Gutenberg din WordPress și în componente. Deci, o opțiune este să obțineți conținut ca HTML. Deci, putem interoga conținutul nostru WordPress ca HTML și apoi putem analiza acel HTML la componente. Sau putem interoga blocurile ca tipuri GraphQL. Deci putem – asta ne permite să interogăm o listă de blocuri, fiecare bloc ar fi un tip GraphQL pe care îl putem mapa la o componentă.

Deci conținutul este HTML. Acesta este ceva ce putem face în nucleul WPGraphQL astăzi. Dacă doriți să interogați blocurile ca tipuri GraphQL individuale, există două opțiuni în acest moment. Avem extensia GraphQL pentru Gutenberg, care este extensia comunității și apoi avem WPGraphQL Block Editor, care este un plugin beta la care lucrez personal.

Și deci să ne uităm la aceste opțiuni. În nucleul WPGraphQL, putem interoga conținutul ca HTML și analiza componentelor. Ceea ce arată este că interogăm ceva de genul unei postări și putem cere câmpuri precum ID și titlu sau conținut. Și conținutul va returna un șir mare, o bucată mare de HTML și apoi putem analiza acel HTML și mapa diferite noduri DOM la diferite componente.

Ca și în acest caz pe wpgraphql.com, linkul din stânga este către codul în care se întâmplă de fapt. Iau marcajul care este returnat de la WPGraphQL și îl analizez, caut anumite noduri HTML și îl convertesc în componente React. Așa că pot avea lucruri interactive, cum ar fi acest bloc de cod, care evidențiază sintaxa și permite utilizatorilor să facă clic pe Copiere și apoi pot, de asemenea, să analizez și să creez un cuprins, de exemplu. Deci aceasta este o abordare. Și îl folosesc astăzi în producție în wpgraphql.com.

Unele lucruri pe care ați putea dori să le luați în considerare dacă mergeți pe această cale, încărcările utile HTML pot fi imprevizibile. Modificările din server, cum ar fi instalarea unei noi biblioteci de blocuri sau diferite HTML pe care editorii le pot pune în conținut, sunt imprevizibile. Deci ar putea fi foarte greu de analizat. Nu puteți interopeta schimbările. În calitate de dezvoltator de clienți, nu puteți vedea ce s-a schimbat, așa că doar ceva de luat în considerare.

Aș spune că această abordare funcționează cel mai bine pentru echipele care au un control foarte strict asupra administratorului WordPress și a front-end-ului. Deci, dacă sunteți o singură persoană sau o echipă mică care lucrează la backend și front-end WordPress, s-ar putea să funcționeze OK pentru dvs., deoarece puteți controla puțin mai bine intrarea și ieșirea.

Una dintre celelalte opțiuni, WPGraphQL pentru Gutenberg, acesta este un plugin întreținut de comunitate. Și acest lucru vă va permite să interogați blocuri de conținut, fiecare bloc ca tipul GraphQL propriu. Modul în care funcționează este o pagină de setări, trebuie să accesați doar blocurile ca schemă, așa că aceasta deschide Gutenberg într-un iframe invizibil, primește registrul de blocuri de la clientul JavaScript și îl trimite la server.

Și apoi putem folosi GraphQL pentru a interoga blocurile noastre ca tipuri specifice și putem folosi fragmente așa cum am arătat mai devreme și putem folosi aceste fragmente pentru a mapa componentele de pe front-end. Deci aceasta este o opțiune. Unele considerații cu acest plugin, modificările aduse registrului de blocuri sunt introspectabile, așa că este un lucru bun.

Echipele care lucrează la aplicația front-end pot folosi introspecția GraphQL pentru a vedea cum se schimbă schema de-a lungul timpului și pot ști dacă există modificări de ultimă oră sau câmpuri noi pe care le pot consuma. Aș spune că această abordare funcționează puțin mai bine pentru proiecte cu mai multe persoane sau cu mai multe echipe. Dacă aveți o echipă care lucrează pe administratorul WordPress și o altă echipă care lucrează pe front-end, această abordare ar putea funcționa mai bine. Ei pot folosi schema GraphQL ca un contract între blocurile care sunt utilizate pe ambele părți.

Un lucru care este puțin interesant este că încarcă blocuri în iframe, așa cum am menționat. Și din această cauză, nu se extinde întotdeauna pentru fiecare situație. Deci, dacă înregistrați blocuri într-o anumită pagină sau într-un anumit șablon sau într-un anumit tip de postare, această metodă de a obține harta registrului de blocuri la schemă poate pierde unele blocuri. Deci s-ar putea să nu se extindă pentru fiecare proiect.

Deci următorul proiect, WPGraphQL Block Editor, acesta este un plugin beta la care lucrez în prezent. Și acest lucru vă permite, de asemenea, să interogați blocurile de conținut ca tipul lor GraphQL și, așadar, foarte asemănător cu WPGraphQL pentru Gutenberg, putem scrie fragmente care returnează datele pe care le specificăm. Și apoi putem folosi acele fragmente cu componentele noastre pe front-end.

Câteva considerații cu aceasta, este un plugin beta, așa că există asta. Beneficiezi de intrarea și ieșirea structurată. Deci, în calitate de dezvoltator front-end, este o victorie cu siguranță. Funcționează cu blocuri care sunt înregistrate cu fișierul block.json. Prin urmare, blocurile de bază WordPress Gutenberg au acest fișier și, deci, acesta va funcționa cu această abordare. O mulțime de terțe părți nu își înregistrează blocurile în acest fel, așa că ar trebui să mapați manual acele blocuri.

Blocurile nu sunt tratate ca noduri individuale. Aș dori să tratez blocurile ca noduri individuale, dar nu există un ID global, așa că trebuie să accesați acele blocuri ca părți ale unor obiecte mai mari, cum ar fi o pagină de poster.

Așa că sper că ați învățat ceva despre WordPress Headless, beneficiile WordPress Headless și despre utilizarea WordPress Headless cu Gutenberg. Vă invit să încercați WPGraphQL astăzi. Vă puteți înscrie pentru un cont gratuit Atlas Sandbox la wpengine.com/atlas. Și vă mulțumesc că v-ați alăturat prezentării mele. Din nou, mă puteți găsi pe Twitter, jasonbahl sau, de asemenea, pe Twitter @wpgraphql. Mulțumesc.