Fragen Sie den Barkeeper: Was passiert, wenn sich das Block-Markup ändert?

Ich bin ein Entwickler, der kürzlich mit der Entwicklung mit Gutenberg begonnen hat. Es gibt eine Menge erstaunlicher Vorteile und Funktionen, aber es gibt auch eine Menge Nachteile, Inkonsistenzen sowie eine absolut schreckliche und veraltete Dokumentation.

Einer der schlimmsten Aspekte von Gutenberg aus Entwicklersicht war die Blockvalidierung. Betrachten Sie das folgende Szenario. Ich erstelle einen benutzerdefinierten (nicht dynamischen) JavaScript-basierten Block, und ein CMS-Editor fügt den Block Tausenden von Seiten hinzu. Was passiert, wenn ich das Markup des Blocks aktualisieren muss?

Standardmäßig werden alle Blöcke in einen ungültigen Zustand versetzt und nicht im Front-End der Website wiedergegeben. Der CMS-Editor müsste in Tausende von Seiten gehen und manuell auf die Schaltfläche klicken, die die Wiederherstellung des Blocks ermöglicht.

Blockablehnungen wurden als Lösung vorgeschlagen, aber die API ist schlecht dokumentiert, verwirrend und scheint mit mehr als ein paar Abwertungen auf lange Sicht nicht mehr wartbar zu sein.

Sollte es nicht entweder eine Möglichkeit für Blockentwickler geben, den Validierungsprozess abzulehnen, oder eine globale Möglichkeit, Blöcke wiederherzustellen?

PJ

Du hältst sicherlich nichts zurück, PJ. Obwohl vieles davon etwas technischer ist, als ich es normalerweise hier in der Taverne behandeln möchte, habe ich mich entschieden, Riad Benguella, einen der führenden Gutenberg-Entwickler, zu kontaktieren, um mehr Einblick in die Situation zu erhalten.

Bevor ich in seine Antwort eintauche, habe ich über einen Aspekt Ihrer Frage nachgedacht. Es gibt Zeiten, in denen Entwickler altes Markup verwerfen und zu etwas Neuem übergehen müssen. Dies sollte jedoch nicht oft vorkommen. Generell ist es ein Zeichen schlechter Architektur, wenn das HTML regelmäßig überarbeitet werden muss. Dies führt auch zu anderen Problemen, wie z. B. dass ein Dritter Stiländerungen nicht beibehalten kann.

Wenn Sie Blöcke oder jede Art von Anwendung entwickeln, die Frontend-Code ausgibt, müssen Sie darüber nachdenken, wie das heute und in 10 Jahren aussehen soll. Was passiert, wenn ein Benutzer benutzerdefiniertes CSS hinzufügt, um Ihren Block zu gestalten, und sich die HTML-Struktur des Blocks geändert hat? Aus ihrer Sicht hat Ihr Block-Update ihre Website beschädigt. Dasselbe könnte man für ein anderes Plugin sagen, das Ihr Plugin in gewisser Weise erweitert.

Fragen Sie einen beliebigen Theme-Autor, wie frustrierend es ist, wenn Gutenberg/WordPress seine Blockausgabe ändert. Obwohl es sich in den letzten Jahren verbessert hat, waren Styling-Blöcke für den Editor und das Frontend oft ein Albtraum für die Wartung.

Als Entwickler habe ich immer versucht, alle realen Konsequenzen dieser Änderungen aus der Perspektive eines Benutzers zu durchdenken. Das sollte ab Tag 1 geschehen, nicht nachdem Sie Ihr Projekt veröffentlicht haben.

Dadurch wird dem frühen Projekt Zeit hinzugefügt, wenn Sie nur versuchen, es aus der Tür und in die Hände der Benutzer zu bringen. Hier hilft es, einen Schritt zurück vor der Veröffentlichung zu machen. Weg vom Computer. Spazieren gehen. Denken Sie über die Architektur Ihres Projekts nach und ob es langfristig ideal ist.

„Die Blockversionierung/-aktualisierung ist in der Tat einer der Bereiche der Gutenberg-APIs, in denen wir architektonische Kompromisse eingehen mussten, und wir haben uns entschieden, die Benutzererfahrung gegenüber der des Entwicklers zu bevorzugen“, sagte Benguella.

Unabhängig von Ihrer Entwicklungsmethode hilft es langfristig, dem Projektansatz einer User-First-Experience zu folgen.

„Um das Problem richtig zu verstehen, muss man verstehen, wie Blöcke funktionieren und bearbeitet werden“, sagt Benguella. „Blockinstanzen sind ein JSON-Objekt, und die Benutzeroberfläche des Editors manipuliert diesen JSON, aber um abwärtskompatibel zu bleiben, um sicherzustellen, dass die Inhalte des Benutzers im am besten lesbaren Format erhalten bleiben, und um Webstandards so weit wie möglich zu übernehmen, der Blockeditor speichert das JSON-Objekt nicht, sondern eine HTML-Serialisierung davon in post_content .

Diese Serialisierung wird analysiert und in JSON konvertiert, wenn der Editor den Inhalt neu lädt, um ihn erneut zu bearbeiten. In der Endphase des Parsens liegt es am Blockautor, zu entscheiden, wie das Objekt gespeichert und geparst wird.

„Stellen Sie sich nun vor, ein Benutzer würde den gespeicherten HTML-Code (Serialisierung) ändern und einfach beliebige Inhalte dort einfügen“, sagte Benguella. „Der Block ist möglicherweise nicht in der Lage, den HTML-Code richtig zu parsen, da er nicht seinen Erwartungen entspricht (was vom Blockautor definiert wurde), was bedeutet, dass das Neuerstellen dieses JSON-Objekts zur Bearbeitung an dieser Stelle nicht möglich ist .“

In diesem Fall bietet der Blockeditor dem Benutzer eine Schnittstelle, um eine fundierte Entscheidung zu treffen. Sie können versuchen, den JSON-Block „zu parsen“ oder ihn in einen HTML- oder Classic-Block umzuwandeln.

Dieselbe Art der Invalidierung kann passieren, wenn ein Plugin-Entwickler seinen Block aktualisiert. Anstelle der gespeicherten HTML-Änderung änderte der Entwickler jedoch die „Erwartungen“ des Blocks – und änderte, wie er gespeichert und analysiert wird.

„Deshalb bitten wir Blockentwickler, Blockabwertungen bereitzustellen, die das alte Markup desselben Blocks darstellen“, sagte Benguella. „Abwertungen können auch als gültige alternative Quellen für denselben Block betrachtet werden. Dadurch kann der Editor das alte Markup beim Laden parsen und das neue Markup zurückspeichern, wenn der Block aktualisiert wird.“

WordPress verfügt über eine Blockablehnungsdokumentation. Es ist jedoch nicht gründlich. Die beste Quelle, um Abwertungen in der realen Welt zu sehen, ist das Durchsuchen der Blockbibliothek von Gutenberg. Veraltete Blöcke haben eine deprecated.js -Datei.

Benguella sagte, dass dieses System für Blockautoren frustrierend sein kann. Dies macht sich besonders in einer Entwicklungsumgebung bei Änderungen bemerkbar. Dies hat Entwickler dazu veranlasst, nach einer Methode zum Deaktivieren des Validierungsalgorithmus zu fragen.

„Das möchten wir im Moment nicht anbieten, da die Validierung, wie oben erläutert, auch dann wichtig ist, wenn sich das Markup aus einem anderen Grund ändert (externe Bearbeitung, anderer Editor usw.)“, sagte er. „Es kann also zu Inhaltsverlusten für Benutzer führen, ohne dass sie sich dessen bewusst sind. Im Moment wird dem Benutzerbewusstsein der Vorzug gegeben.“

Das Team hat das Validierungssystem im Laufe der Zeit verbessert, sodass kleine Änderungen möglich sind, die den Blockstatus nicht unterbrechen. Es gibt auch ein offenes Ticket für zukünftige Verbesserungen.