問酒保：塊標記更改時會發生什麼？

我是一名最近開始與 Gutenberg 一起開發的開發人員。 有很多驚人的好處和功能，但也有很多缺點、不一致以及絕對糟糕和過時的文檔。

從開發人員的角度來看，古騰堡最糟糕的方面之一就是區塊驗證。 考慮以下場景。 我構建了一個自定義（非動態）基於 JavaScript 的塊，CMS 編輯器將該塊添加到數千個頁面。 當我需要更新塊的標記時會發生什麼？

默認情況下，所有的塊都會進入失效狀態，不會在網站前端反映。 CMS 編輯器必須進入數千頁並手動單擊允許恢復塊的按鈕。

有人建議將塊棄用作為解決此問題的一種方法，但該 API 的文檔記錄很差，令人困惑，而且從長遠來看，如果多次棄用，它似乎將變得無法維護。

區塊開發者不應該有一種方法可以選擇退出驗證過程，或者是一種恢復區塊的全局方法嗎？

PJ

PJ，你當然沒有任何保留。 雖然其中大部分內容比我通常喜歡在 Tavern 介紹的技術要多一些，但我決定聯繫 Gutenberg 的主要開發人員之一 Riad Benguella，以更深入地了解情況。

在深入探討他的回答之前，我已經考慮了你問題的一個方面。 有時開發人員需要棄用舊的標記並轉向新的東西。 但是，這不應該經常發生。 一般來說，如果需要定期對 HTML 進行大修，則表明架構不佳。 這也會導致其他問題，例如第三方無法保持風格變化。

在開發模塊或任何類型的輸出前端代碼的應用程序時，您需要考慮現在和 10 年後應該是什麼樣子。 如果用戶添加了一些自定義 CSS 來設置塊樣式並且塊的 HTML 結構發生了變化，會發生什麼？ 從他們的角度來看，您的阻止更新破壞了他們的網站。 對於以某種方式擴展您的插件的另一個插件也可以這樣說。

詢問任何主題作者在 Gutenberg/WordPress 更改其塊輸出時有多麼令人沮喪。 雖然它在過去幾年有所改進，但編輯器和前端的樣式塊通常是維護的噩夢。

作為一名開發人員，我一直試圖從用戶的角度考慮進行這些更改的任何現實後果。 這應該從第一天開始，而不是在您發布項目之後。

當您只是試圖將它推出門並交到用戶手中時，這樣做會增加早期項目的時間。 這就是在發布前退後一步有幫助的地方。 遠離電腦。 去散步。 考慮一下您項目的架構，以及它是否適合長期使用。

“對於塊版本控制/更新，這確實是 Gutenberg API 的領域之一，我們需要在其中進行架構權衡，我們決定優先考慮用戶體驗而不是開發人員的體驗，”Benguella 說。

無論您採用哪種開發方法，從長遠來看，遵循項目的用戶至上體驗方法都會有所幫助。

“要正確理解問題，需要了解塊的工作方式和編輯方式，”Benguella 說。 “塊實例是一個 JSON 對象，編輯器 UI 操作該 JSON，但為了保持向後兼容，確保以最易讀的格式保存用戶內容，並儘可能地採用 Web 標準，塊編輯器不存儲 JSON 對象，而是在post_content中存儲它的 HTML 序列化。”

當編輯器重新加載內容以再次編輯時，該序列化被解析並轉換為 JSON。 在解析的最後階段，由塊作者決定如何保存和解析對象。

“現在，想像一下，如果用戶更改了保存的 HTML（序列化）並在其中放置任何隨機內容，”Benguella 說。 “該塊可能無法正確解析 HTML，因為它不符合其預期（由塊作者定義），這意味著此時無法重新創建該 JSON 對像以進行操作。”

發生這種情況時，塊編輯器會為用戶提供一個界面以做出明智的決定。 他們可以嘗試“強制解析”塊 JSON 或將其轉換為 HTML 或經典塊。

當插件開發人員更新他們的塊時，可能會發生這種相同類型的失效。 然而，開發人員並沒有改變保存的 HTML，而是改變了塊的“期望”——改變了它的保存和解析方式。

“這就是為什麼我們要求區塊開發者提供代表同一區塊的舊標記的區塊棄用，”Benguella 說。 “棄用也可以被認為是同一區塊的有效替代來源。 這允許編輯器在加載時解析舊標記，並在對塊進行更新時保存新標記。”

WordPress 有塊棄用文檔。 然而，它並不徹底。 查看實際棄用的最佳來源是查看 Gutenberg 的塊庫。 不推薦使用的塊有一個deprecated.js文件。

Benguella 說，這個系統可能會讓區塊作者感到沮喪。 這在開發環境中進行更改時尤其明顯。 這導致開發人員要求提供一種禁用驗證算法的方法。

“這是我們目前不想提供的東西，因為如上所述，當標記因其他原因（外部編輯、另一個編輯器等）而發生變化時，驗證也很重要，”他說。 “因此，它可能會在用戶不知情的情況下導致內容丟失。 目前優先考慮的是用戶意識。”

該團隊隨著時間的推移改進了驗證系統，允許在不破壞塊狀態的情況下進行小的更改。 還有一張開放的票可以在未來進行改進。