DE{CODE}: Gutenberg und Headless WordPress

Gutenberg, auch bekannt als WordPress-Blöcke, bietet Inhaltsproduzenten leistungsstarke neue Möglichkeiten, Inhalte auf einer traditionellen WordPress-Site zu gestalten. Aber wie können Headless-WordPress-Entwickler Marketingteams mit denselben Fähigkeiten ausstatten? In dieser DE{CODE}-Sitzung teilt der Gründer von GraphQL für WordPress (WPGraphQL), Jason Bahl, neue Funktionen und Best Practices für die Verwendung des WordPress-Blockeditors auf einer Headless-Site.

Sitzungsfolien

Vollständige Textabschrift

JASON BAHL : Hallo. Willkommen zu meinem Vortrag über Gutenberg und Headless WordPress. Mein Name ist Jason Bahl. Ich bin der Ersteller und Betreuer von WPGraphQL. Ich bin leitender Softwareentwickler bei WP Engine. Sie finden mich auf Twitter @jasonbahl oder auch auf Twitter @wpgraphql.

Deshalb möchte ich heute mit Ihnen darüber sprechen, was Gutenberg überhaupt ist, Headless WordPress ist, wann und warum Sie Headless WordPress verwenden möchten, wie Sie Gutenberg speziell mit Headless WordPress verwenden können und wann und warum Headless WordPress und Gutenberg zusammen könnte für Ihre Projekte sinnvoll sein.

WordPress hatte also in der Vergangenheit einen Editor, der ein bisschen so aussah. Wir hatten einen TinyMCE-Textbereich, in dem wir unsere Inhalte bearbeiten können. Wir können Medien einfügen und dann unsere Inhalte veröffentlichen, und dann kam 2018 Gutenberg, dieser blockbasierte Editor, der es uns ermöglicht, Inhalte in diese leere Leinwand einzufügen und mit unseren Inhalten auf Blockebene zu interagieren.

Jeder Absatz hat also Einstellungen. Jedes Bild hat Einstellungen. Jede Galerie, jede Überschrift – alles, was Sie sich für den Inhalt vorstellen können, wird als Block bezeichnet. Und wir können unsere Inhalte jetzt sehr genau steuern und sie per Drag-and-Drop verschieben und unsere Inhalte zusammenstellen. Es ist also diese sehr reichhaltige Bearbeitungserfahrung in WordPress und damit eine Einführung in das, was Gutenberg ist.

Was ist nun Headless WordPress? Um Headless zu verstehen, schauen wir uns also traditionelles WordPress an. Also traditionelles WordPress, wir melden uns bei WordPress an, der Admin-Benutzeroberfläche, und wir veröffentlichen unsere Inhalte, und dann besuchen die Benutzer unsere Website, und PHP, die in WordPress integrierte Sprache, rendert die Seite. Es lädt also CSS, HTML und JavaScript und liefert die Seite an den Benutzer. Das ist also eine Art traditionelles WordPress.

Bei Headless WordPress verwenden Sie weiterhin WordPress als CMS. Sie veröffentlichen immer noch Inhalte, kuratieren Inhalte, verwalten Inhalte in WordPress, aber anstatt eine Seite in HTML an den Browser zu liefern, liefert WordPress Daten typischerweise im JSON-Format, und dann können Client-Anwendungen diese Daten nutzen, sodass wir native iOS- oder Android-Anwendungen haben können oder sogar Virtual-Reality-Anwendungen.

Mein Kollege Anthony hat Inhalte darüber geteilt, wie er WordPress verwendet, um Virtual-Reality-Anwendungen zu betreiben. Oder ich habe bei einer Zeitung gearbeitet, wo wir WordPress als Einstiegspunkt für unsere Printzeitungen verwendet haben. Wenn Sie also eine gedruckte Zeitung lesen, lesen Sie Inhalte, die in WordPress erstellt wurden.

Und natürlich können wir diese Daten auch zum Rendern im Web verwenden, aber anstatt an PHP-Templates gebunden zu sein, haben wir die Flexibilität, die gewünschte Front-End-Technologie zu wählen. Headless entkoppelt also das Backend, die Verwaltung von Inhalten und die Art und Weise, wie wir die in WordPress verwalteten Daten präsentieren.

Es gibt also zwei gängige Möglichkeiten, wie wir diese Daten verwenden können. Wir können Daten im JSON-Format von der WP REST API abrufen, die eine integrierte API für WordPress ist, und es gibt eine weitere API namens WPGraphQL. Dies ist ein Open-Source-Plugin, das Sie installieren und Daten aus WordPress und JSON abrufen können. Und wir werden heute über WPGraphQL sprechen.

Nun, da wir wissen, was WordPress ist, warum sollten Sie Headless-WordPress-Projekte erstellen? Wie ich bereits erwähnt habe, haben Sie viel Flexibilität bei der Auswahl Ihrer Front-End-Technologie. Und für einige Leute ist es sehr wichtig, dass sie wählen können, wie sie die Front-End-Projekte erstellen. Es gibt einige Frameworks wie Next und Gatsby und Svelte, die wirklich auf verbesserte Core-Web-Vitals abzielen. So können Sie mit WordPress möglicherweise Headless verwenden und haben verbesserte Kern-Web-Vitals.

Sie können von Dingen wie Code-Splitting in Ihrem Code profitieren. So können Sie Komponenten für Ihre Frontend-Anwendung bauen. Und je nachdem, welche Komponente für die jeweilige Seite entwickelt wird, werden weniger oder weniger Assets an den Client gesendet und Ihre Seiten beschleunigt. Headless gibt Entwicklern auch eine genauere Kontrolle über die Front-End-Benutzererfahrung, sodass Plugins, die im WordPress-Adminbereich installiert sind, weniger Einfluss auf das Front-End haben

Admin-Benutzer können also nicht einfach Plugins installieren und beliebige Skripte oder beliebiges Markup zum Front-End einer Headless-Site hinzufügen lassen. Es ist eher ein Entwickler, der die Einschränkungen für das Front-End definiert und WordPress die Daten übermittelt, und dann möchte ich unter anderem die Entwicklererfahrung eingeben.

Da Sie mit Headless WordPress die Flexibilität haben, jeden gewünschten Tech-Stack zu verwenden, gibt es in einigen Fällen den Vorteil einer besseren Entwicklererfahrung. Und einer dieser Fälle, auf die ich eingehen werde, heißt komponentenbasierte Entwicklung, und wir werden gleich viel darüber sprechen.

Das sind also einige Gründe, warum. In welchen Situationen könnten Sie also sein, wenn Sie Headless WordPress verwenden möchten? Nun, wenn Sie Nicht-Web-Anwendungen wie native mobile Anwendungen erstellen müssen, möchten Sie wahrscheinlich zu Headless wechseln. Auch hier gilt: Wenn Ihre wichtigsten Web-Vitals auf Ihrer WordPress-Site, Ihrer aktuellen WordPress-Site oder in Ordnung sind, es aber sehr kostspielig wird, sie gut zu halten, sollten Sie Headless in Betracht ziehen.

Wenn Sie mehrere Anwendungen in Ihrer Organisation haben, die Daten aus WordPress abrufen müssen, müssen Sie möglicherweise auch auf Headless umsteigen. Und wenn Sie bereits in eine Komponentenbibliothek oder ein komponentenbasiertes Designsystem für Ihr Unternehmen investiert haben und Daten aus WordPress benötigen, sollten Sie vielleicht in Headless investieren. Wenn ein Team JavaScript bevorzugt und nicht gerne Dinge in PHP baut, ist das auch ein Grund, Headless in Betracht zu ziehen.

Es gibt jedoch einige Gründe, warum Sie Headless nicht verwenden möchten – derzeit dauert die Entwicklung etwas länger. Wenn Sie also ein geringeres Budget haben oder die Zeit zurückschrauben und bereits Lösungen in traditionellem WordPress haben, gehen Sie möglicherweise noch nicht Headless. Wenn Ihre Site-Administratoren wirklich die Kontrolle über die Installation von Plugins benötigen, die das Frontend modifizieren, gehen Sie möglicherweise noch nicht Headless.

Wenn Ihr Team PHP wirklich bevorzugt und kein JavaScript oder alternative Frontends lernen möchte, können Sie auch bei traditionellem WordPress bleiben. Und wenn Sie nicht in eine komponentenbasierte Entwicklung oder komponentenbasierte Bibliothek investiert haben, wenn Sie daran kein Interesse haben, bleiben Sie möglicherweise bei traditionellen WordPress-Entwicklungsworkflows.

Und wenn Ihre wichtigsten Web-Vitals auf Ihrem traditionellen WordPress wirklich gut sind und Ihre Wartungskosten sehr niedrig sind, damit Ihre Website sehr schnell läuft, können Sie vielleicht bei traditionellem WordPress bleiben. Sie müssen also nicht Headless gehen. Aber ich werde Ihnen zeigen, warum ich denke, dass Headless für einige Teams gut sein kann.

Wenn wir uns also noch einmal die WordPress-Entwicklererfahrung ansehen, veröffentlichen wir unsere Inhalte in einem Feld, das einen großen Teil des HTML generiert. Und selbst wenn wir den Gutenberg-Editor verwenden, der diese granularen Blöcke enthält, ist das Endergebnis ein großer HTML-Block. Unabhängig davon, ob wir in Gutenberg oder im traditionellen klassischen Editor veröffentlichen, wird dieser HTML-Teil über PHP an unser Design gesendet, und wir haben eine globale Seite, die unser HTML, unser CSS und unser JavaScript lädt. Und diese Assets werden global auf die Seite angewendet.

Daher entkoppeln WordPress-Entwickler unsere Entwicklung in der Regel basierend auf Dateitypen, sodass wir unser CSS in separaten Dateien ablegen, die global auf die Seite angewendet werden, oder HTML wird in PHP geschrieben und die Daten, die wir benötigen, aus WordPress und dann aus JavaScript abrufen oft mal mit jQuery in separate Dateien geschrieben werden. Und so kommen diese drei Dinge zusammen, um die Seite zu erstellen.

Das Problem ist, dass diese nicht isoliert sind, sondern auf die ganze Seite angewendet werden. So können Sie manchmal etwas ändern. So wie es mir passiert ist. Einmal nahm ich auf Wunsch meines Managers eine Änderung an einem Stil in der Fußzeile einer Website vor, und drei Tage später wurde gemeldet, dass sich der Stil an anderer Stelle auf der Website aufgrund dieser Überprüfung des Passcodes geändert hatte. Wir haben es bestanden.

Plötzlich war etwas anderes auf der Website kaputt und das, weil CSS global angewendet wird und sich auf Dinge auswirken könnte, die Sie nicht erkennen. Es gibt jedoch einen neuen Trend, der in den vergangenen – ich weiß nicht – sieben, acht Jahren vielleicht als komponentenbasierte Architektur bezeichnet wird. Auf diese Weise können wir bestimmte Teile unserer Anwendung in sogenannten Komponenten erstellen.

Und wir können unser JavaScript, unser HTML, unser CSS in kleine Teile koppeln, die wir isoliert testen können, und so können wir Teile unserer Anwendung erstellen. Ein paar Bedenken, das Markup, die JavaScripts, die Stile, und wir können diese Komponenten zusammensetzen, um komplexere Anwendungen zu erstellen.

Die komponentenbasierte Entwicklung ermöglicht es uns also, komplexe Funktionen in kleinere, isolierte Teile zu zerlegen, und wir können sie isoliert testen, sicherstellen, dass sie funktionieren, und dann können wir unsere Anliegen, die gekoppelt werden sollten, koppeln. Jeder Teil der Benutzeroberfläche hat eine spezifische Verantwortung. Wenn es sich um eine Bildkarte handelt, ist sie möglicherweise dafür verantwortlich, das Bild in einer bestimmten Größe mit einer bestimmten URL zu rendern.

Es hat also Markup-Abhängigkeiten. Es hat Stilabhängigkeiten. Es könnte zustandsbehaftete Interaktionen haben. Diese beziehen sich alle auf diese spezifische Komponente. So können wir unser Markup, unser JavaScript und unser CSS an einem Ort koppeln, testen und sicherstellen, dass es gut funktioniert. Aus diesem Grund können wir diese Komponenten dann in unserer gesamten Anwendung wiederverwenden, oder wir können unsere Komponenten sogar projektübergreifend wiederverwenden.

Es gibt also einen Trend namens Komponentenbibliotheken. Es gibt Projekte wie Material UI oder Enddesignkomponenten, oder Chakra UI ist ebenfalls sehr beliebt. Und wir können diese Komponenten projektübergreifend nutzen. Und wir können zentrale Anliegen wie barrierefreies Markup lösen. Und wir können diese aktualisieren und sie auf mehrere Projekte in unserer Organisation gleichzeitig anwenden, und aus diesen Gründen können wir oft mit viel mehr Vertrauen schneller iterieren und versenden.

Wie können wir dann Headless WordPress verwenden? Wie ich bereits erwähnt habe, gibt es zwei Möglichkeiten, Daten aus WordPress heraus und in Komponenten zu übertragen. Eine wäre die REST-API. Einer wäre WPGraphQL. Mein Freund Drake baut seit einiger Zeit Headless-Sites, also habe ich ihn gefragt und das ist, was er sagte ...

Er bevorzugt WPGraphQL. Darüber werden wir also heute sprechen. Was ist also WPGraphQL? Sie könnten fragen. Nun, es ist ein kostenloses Open-Source-WordPress-Plugin, das ein erweiterbares GraphQL-Schema und eine API für jede WordPress-Site bereitstellt. Was ist dann GraphQL? Nun, es ist eine Graph-Abfragesprache.

In Ordnung, Jason. Ich verstehe immer noch nicht, was du sagst. In Ordnung, also lass es mich dir zeigen. GraphQL funktioniert also so, dass Client-Anwendungen eine Anfrage senden, die angibt, was sie vom Server wollen. Und so sieht eine Anfrage aus. Es sieht aus wie JSON-Schlüssel ohne Werte. In diesem Fall fragt die Anfrage also nach dem Betrachter, und bei einem Betrachter möchten wir, dass das Feld „Name“ zurückgegeben wird.

Und eine Antwort vom GraphQL-Server könnte so aussehen. Seine tatsächlichen JSON-Daten, Schlüssel und Werte entsprechen der Form der Anfrage. In diesem Fall erhalten wir also den Namen oder den Zuschauer mit dem Namen Jason Bahl. Mit GraphQL können wir also Client-Anwendungen Bäume aus dem Anwendungsdatendiagramm pflücken.

Und wie das optisch aussieht ist in etwa so. Wir können den Graphen eingeben, sagen wir, ein Viewer oder Benutzerfeld oder einen Knoten hinzufügen. Und dieser Knoten könnte eine Eigenschaft wie den Namen Jason haben. Und dieser Knoten könnte Verbindungen zu anderen Knoten im Diagramm haben, wie ein Avatar, der eine Eigenschaft wie eine Bild-URL haben könnte.

Und dieser Benutzer hat möglicherweise Verbindungen zu anderen Knoten, z. B. Post, die dieser Benutzer verfasst hat. Und diese Beiträge können selbst Eigenschaften wie einen Titel, Hallo Welt oder Auf Wiedersehen Mars haben. Und diese Beiträge können Verbindungen zu anderen Knoten im Diagramm haben, z. B. Kategorien mit eigenen Titeln wie Nachrichten oder Sport. Und diese Kategorien können auch Verbindungen zu anderen Knoten haben, wie z. B. mehr Posts. Und diese Posts könnten Bilder enthalten und so weiter und so weiter. Wir haben also dieses große Datendiagramm, das wir mit GraphQL nach Teilen fragen können.

Und so können wir Tools im GraphQL-Admin oder im WordPress-Admin verwenden. Es gibt ein Tool namens GraphiQL, mit dem ich eine Abfrage erstellen kann. Und hier wähle ich das Viewer-Feld mit Unterauswahlen, Name, Avatar, der URL aus, und wenn wir das ausführen, erhalten wir die Felder, nach denen wir fragen, und so sieht die Abfrage visuell ein bisschen so aus.

Wir haben das Diagramm betreten und nach einem Benutzer gefragt. Wir fragten nach dem Namen des Benutzers, dem verbundenen Avatar in der URL des Avatars. Wir haben alle diese Datendiagramme zur Verfügung, aber wir fragen nur nach einem bestimmten Datensatz und als Antwort haben wir diesen bestimmten Rückschlag zurückerhalten. Und dann können wir nehmen – wir können jetzt Komponenten verwenden.

Also habe ich über die Vorteile der komponentenbasierten Entwicklung gesprochen, und ich möchte Ihnen dies in Aktion zeigen. Und das ist es, was ich eine Präsentationskomponente nennen würde. Das ist also eine Kartenkomponente, die dafür verantwortlich ist. Es hat eine Verantwortung dafür, diese Karte mit einem Bild und einem Titel zu rendern.

Und wir können uns den Code ansehen und wir sehen, dass wir eine gewisse Stilkontrolle haben. Wir können die Breite festlegen, wir können ihm das gewünschte Bild übergeben und wir können ihm den Titel übergeben. So können wir diese Komponente während unseres gesamten Projekts wiederverwenden. Und diese Komponente hat alle Abhängigkeiten, die wir brauchen. Es hat das zu rendernde HTML. Es hat die Stile. Wir haben hier eine gewisse Stilkontrolle. Es hat einige zustandsbehaftete Komponenten wie den Schwebezustand und so weiter.

Das ist also eine isolierte Komponente, die wir wiederverwenden können, und mit GraphQL können wir jetzt die Abfrage, die wir gerade im WordPress-Admin erstellt haben, mit GraphQL nehmen und sie einbringen und haben jetzt eine Viewer-Card-Komponente. Wir können also unsere Abfrage schreiben, sie mit unserer Kartenkomponente koppeln und jetzt vervollständigt sie die Komponente.

Wir haben unser HTML, CSS unser JavaScript. Und aufgrund der Daten haben wir jetzt etwas zu rendern mit den Daten, um die wir gebeten haben. Jetzt können wir dies in unserer gesamten Anwendung verwenden, und es gibt eine Funktion von GraphQL namens Fragmente, die es uns ermöglicht, unsere GraphQL-Abfragen zu nehmen und sie in wiederverwendbare Teile zu zerlegen.

In diesem Fall erstelle ich also ein Fragment einer Benutzerprofilkarte und gebe Name, Avatar und URL an und verwende dieses Fragment dann in einer größeren Abfrage. Bei der Ausführung erhalten wir die Ergebnisse, die wir erwarten. Wir können dieses Fragment jetzt nehmen und es in eine Komponente stecken. Jetzt haben wir eine andere Komponente namens User Profile Card.

Diese Benutzerprofilkarte gibt an, dass wir jedes Mal, wenn wir einen Benutzer abfragen, den Namen, den Avatar und die URL des Avatars erhalten sollten, die in der Komponente verwendet werden sollen. Jetzt haben wir also diese wiederverwendbare Komponente, mit der wir überall in unserer Anwendung nach einem Benutzer fragen und die Daten abrufen können, die zum Rendern dieser wiederverwendbaren Karte mit dem Avatar und dem Namen des Benutzers erforderlich sind.

Und so kann dies nun in größere Teile unserer Anwendung eingebracht und verwendet werden. Hier ist also die Abfrage, die wir vor der Viewer-Abfrage mit dem Fragment hatten, das wir aus einer wiederverwendbaren Benutzerprofilkartenkomponente importieren. Und dann geben wir es an eine Viewer-Card-Komponente aus und können es jetzt in unserer gesamten Anwendung wiederverwenden.

Wir können größere Teile unserer Anwendung erstellen, die sich auf diese Benutzerkarte oder die Autorenkarte stützen. So können wir jetzt mehrere Komponenten haben, wie z. B. die Blog-Titelkomponente, die für den Titel verantwortlich ist. Wir können eine gerade erstellte Benutzerprofilkarte haben, die das Profil des Benutzers darstellt. Wir können eine Inhalts- oder Auszugskomponente haben, die für das Markup und die Daten für diesen Teil unserer Anwendung verantwortlich ist.

Und ja, wir können diese kleinen Komponenten erstellen, die für das Markup, das CSS und die zum Erstellen dieser Anwendung erforderlichen Daten verantwortlich sind. Und wir können sie zusammen komponieren. Wir können sie isoliert testen, auch als größere Einheiten testen. Wir können dies also auch in verschiedenen Vorlagen verwenden.

Wir können diese wiederverwendbaren Komponenten für einen Blog-Beitrag oder unsere Blog-Rolle verwenden, wenn wir unterschiedliche Autoren haben, aber wir können dieselbe Komponente verwenden, um sie zu rendern. Wir können es für die andere Archivseite verwenden. So ähnlich wie WordPress-Vorlagenteile, können wir unsere Headless-Anwendungen in kleine Teile zerlegen, aber wir haben den Vorteil, unsere Technologie miteinander zu koppeln.

Das ist also ein bisschen über Headless WordPress-Entwickler, die komponentenbasiertes Design und die Vorteile davon erfahren. Wenn es also speziell um Gutenberg geht, warum sollten Sie Headless WordPress mit Gutenberg speziell in Betracht ziehen? Nun, wenn Ihr Team bereits Headless WordPress verwendet, möglicherweise mit Advanced Custom Fields und Flexfields, und Sie die Editor-Erfahrung aktualisieren möchten, um Gutenberg zu verwenden, ist dies offensichtlich ein Grund, warum Sie Headless mit Gutenberg verwenden könnten.

Wenn Sie davon profitieren möchten, Komponenten zu erstellen, die im Admin und im Frontend verwendet werden, ist dies ein guter Grund, Headless mit Gutenberg zu verwenden, da der Gutenberg-Backend-Editor des Blockeditors vollständig komponentenbasiert ist. Vielleicht möchten Sie die strukturierte Eingabe nutzen. Jeder Block im Admin hat Felder, die strukturiert sind.

Sie haben bestimmte Attribute, die Sie auf Feldebene steuern können. Und vielleicht möchten Sie davon profitieren, dass diese strukturierte Ausgabe auch zu Ihren Komponenten kommt. Und wie ich bereits erwähnt habe, möchten Sie möglicherweise Komponenten und Blöcke projektübergreifend wiederverwenden. Vielleicht möchten Sie eine von Ihrer Agentur erstellte Blockbibliothek haben, die Dinge wie Barrierefreiheit und bestimmte Markup-Probleme löst, die Sie projektübergreifend verwenden möchten. Und dann können Sie diese projektübergreifend aktualisieren, nicht nur innerhalb eines einzelnen Projekts.

Dies ist also ein Teil, in dem ähnliche untergeordnete Themen in WordPress schwierig zu skalieren sein können, da Sie zu jeder einzelnen Site gehen müssen, um das Markup und so weiter auf jeder einzelnen Site zu aktualisieren. Nun, hier können Sie Blockbibliotheken als NPM-Abhängigkeiten verwenden und sie in Ihrer gesamten Organisation aktualisieren.

Der aktuelle Stand der WordPress-Entwicklung mit Gutenberg ist also, dass wir Blöcke im Backend haben, die komponentenbasiert sind. Wir können unsere eigenen benutzerdefinierten Blöcke erstellen oder grundlegende WordPress-Blöcke verwenden. Aber die Ausgabe in PHP ist, wie ich bereits erwähnt habe, ein großer HTML-Block. Wie können wir also von diesem einen HTML-Block zu Komponenten im Backend übergehen, die auch an Komponenten in unserem Frontend übertragen werden?

Wir werden uns also einige Optionen ansehen, um Gutenberg-Daten aus WordPress heraus und in Komponenten zu übertragen. Eine Möglichkeit besteht also darin, Inhalte als HTML zu erhalten. So können wir unseren WordPress-Inhalt als HTML abfragen und diesen HTML-Code dann in Komponenten zerlegen. Oder wir können Blöcke als GraphQL-Typen abfragen. Wir können also – das erlaubt uns, eine Liste von Blöcken abzufragen, jeder Block wäre ein GraphQL-Typ, den wir einer Komponente zuordnen können.

Der Inhalt ist also HTML. Dies ist etwas, was wir heute im WPGraphQL-Kern tun können. Wenn Sie Blöcke als einzelne GraphQL-Typen abfragen möchten, gibt es derzeit zwei Möglichkeiten. Wir haben die GraphQL for Gutenberg-Erweiterung, eine Community-Erweiterung, und dann haben wir den WPGraphQL Block Editor, ein Beta-Plugin, an dem ich persönlich arbeite.

Schauen wir uns also diese Optionen an. Im WPGraphQL-Kern können wir Inhalte als HTML abfragen und in Komponenten zerlegen. Das sieht so aus, dass wir so etwas wie einen Beitrag abfragen und nach Feldern wie ID und Titel oder Inhalt fragen können. Und der Inhalt wird einen großen String zurückgeben, einen großen HTML-Block, und dann können wir diesen HTML-Code parsen und verschiedene DOM-Knoten verschiedenen Komponenten zuordnen.

Wie in diesem Fall auf wpgraphql.com führt der Link auf der linken Seite zu dem Code, in dem dies tatsächlich geschieht. Ich nehme das Markup, das von WPGraphQL zurückgegeben wird, und ich parse es, suche nach bestimmten HTML-Knoten und konvertiere es in React-Komponenten. Ich kann also interaktive Dinge wie diesen Codeblock haben, der die Syntaxhervorhebung durchführt und es den Benutzern ermöglicht, auf Kopieren zu klicken, und dann kann ich zum Beispiel auch ein Inhaltsverzeichnis analysieren und erstellen. Das ist also ein Ansatz. Und ich verwende es heute in wpgraphql.com in der Produktion.

Einige Dinge, die Sie vielleicht berücksichtigen sollten, wenn Sie diesen Weg gehen, können HTML-Nutzlasten unvorhersehbar sein. Änderungen am Server wie die Installation einer neuen Blockbibliothek oder verschiedener HTML-Codes, die Redakteure in Inhalte einfügen können, sind unvorhersehbar. Es könnte also sehr schwer zu analysieren sein. Sie können die Änderungen nicht interoptieren. Als Client-Entwickler können Sie nicht sehen, was sich geändert hat, also sollten Sie nur etwas beachten.

Ich würde sagen, dass dieser Ansatz am besten für Teams funktioniert, die eine sehr strenge Kontrolle über den WordPress-Admin und das Front-End haben. Wenn Sie also eine einzelne Person oder ein kleines Team sind, das am WordPress-Backend und am Frontend arbeitet, funktioniert es möglicherweise für Sie, da Sie die Eingabe und Ausgabe etwas besser steuern können.

Eine der anderen Optionen, WPGraphQL für Gutenberg, ist ein von der Community gepflegtes Plugin. Auf diese Weise können Sie Inhaltsblöcke abfragen, und zwar jeden Block als eigenen GraphQL-Typ. Dies funktioniert über eine Einstellungsseite, Sie müssen nur die Blöcke als Schema eingeben, damit Gutenberg in einem unsichtbaren Iframe geöffnet wird, die Blockregistrierung vom JavaScript-Client abgerufen und an den Server gesendet wird.

Und dann können wir GraphQL verwenden, um unsere Blöcke als bestimmte Typen abzufragen, und wir können Fragmente verwenden, wie ich zuvor gezeigt habe, und wir können diese Fragmente verwenden, um Komponenten in unserem Front-End zuzuordnen. Das ist also eine Möglichkeit. Einige Überlegungen zu diesem Plugin, Änderungen an der Blockregistrierung sind selbstprüfbar, also ist das eine gute Sache.

Teams, die an der Front-End-Anwendung arbeiten, können die GraphQL-Introspektion verwenden, um zu sehen, wie sich das Schema im Laufe der Zeit ändert, und sie können wissen, ob es Breaking Changes oder neue Felder gibt, die sie verwenden können. Ich würde sagen, dass dieser Ansatz für Projekte mit mehreren Personen oder mehreren Teams etwas besser funktioniert. Wenn Sie ein Team haben, das am WordPress-Admin arbeitet, und ein anderes Team, das am Frontend arbeitet, funktioniert dieser Ansatz möglicherweise besser. Sie können das GraphQL-Schema als Vertrag zwischen den Blöcken verwenden, die auf beiden Seiten verwendet werden.

Eine Sache, die ein wenig interessant ist, ist, dass es Blöcke in den Iframe lädt, wie ich erwähnt habe. Und aus diesem Grund skaliert es nicht immer für jede Situation. Wenn Sie also Blöcke für eine bestimmte Seite oder eine bestimmte Vorlage oder einen bestimmten Beitragstyp registrieren, werden bei dieser Methode zum Abrufen der Blockregistrierungszuordnung zum Schema möglicherweise einige Blöcke übersehen. Es kann also nicht für jedes Projekt skaliert werden.

Das nächste Projekt, WPGraphQL Block Editor, ist ein Beta-Plugin, an dem ich derzeit arbeite. Und dies ermöglicht Ihnen auch, Inhaltsblöcke als eigenen GraphQL-Typ abzufragen, und so ähnlich wie WPGraphQL für Gutenberg können wir Fragmente schreiben, die die von uns angegebenen Daten zurückgeben. Und dann können wir diese Fragmente mit unseren Komponenten im Front-End verwenden.

Einige Überlegungen dazu, es ist ein Beta-Plugin, also gibt es das. Sie profitieren von strukturiertem Input und strukturiertem Output. Als Frontend-Entwickler ist das also sicher ein Gewinn. Es funktioniert mit Blöcken, die in der Datei block.json registriert sind. Die Kernblöcke von WordPress Gutenberg haben also diese Datei und das funktioniert mit diesem Ansatz. Viele Drittanbieter registrieren ihre Blöcke nicht auf diese Weise, sodass Sie diese Blöcke manuell zuordnen müssten.

Blöcke werden nicht als einzelne Knoten behandelt. Ich würde gerne Blöcke als einzelne Knoten behandeln, aber es gibt keine globale ID, also müssen Sie auf diese Blöcke als Teile größerer Objekte wie einer Posterseite zugreifen.

Ich hoffe, Sie haben etwas über Headless WordPress, die Vorteile von Headless WordPress und die Verwendung von Headless WordPress mit Gutenberg gelernt. Ich lade Sie ein, WPGraphQL noch heute auszuprobieren. Sie können sich unter wpengine.com/atlas für ein kostenloses Atlas Sandbox-Konto anmelden. Und danke, dass Sie an meiner Präsentation teilgenommen haben. Auch hier finden Sie mich auf Twitter, jasonbahl, oder auch auf Twitter @wpgraphql. Danke schön.