React-Gutenberg Bridge 簡介：Headless Block 支持更好的編輯體驗

您對無頭 WordPress 提供的機會感到興奮，但您客戶的營銷團隊依賴於所見即所得的古騰堡編輯器。

了解 Faust 對無頭項目的新 Gutenberg 塊支持如何將兩者結合在一起，使您的開發現代化，同時為您的營銷人員提供支持。

演講嘉賓：

• WP Engine 的軟件工程師 Teresa Gobble
• WP Engine 高級軟件工程師 Blake Wilson

會議幻燈片：

成績單：

TERESA GOBBLE： 大家好。 我的名字是特蕾莎·戈布爾。 我是 Faust 團隊的 WP Engine 軟件工程師。

我和高級軟件工程師 Blake Wilson 在這裡向您介紹 React-Gutenberg Bridge——無頭塊支持，可提供更好的編輯體驗。 歡迎。 讓我們開始吧。

所以今天，我們有很多內容要講。 首先，我將介紹一些與問題相關的事情和我們為您提供的解決方案，以及 React-Gutenberg Bridge 的價值。 然後我們將去找 Blake，他將為我們提供 React-Gutenberg Bridge 的實際演示。 之後，我們將討論幾個技術細節。 我們還將訪問我們為此準備的未來路線圖。

所以這就是問題所在。 沒有將 Gutenberg 塊從 WordPress 轉換為無頭前端的簡化方法。 現有的解決方案尚不能擴展或直觀地提供無頭開發人員可以期望的開發人員體驗。

解耦打破了在編輯器中自然使用古騰堡塊內容的能力。 各機構想知道他們是如何按照自己的方式或在幾乎沒有指導的情況下從頭開始的。 還有很多懸而未決的問題留給人們。

造型呢？ 可重用性、動態塊、InnerBlocks 怎麼樣？ 那麼，這就是 React-Gutenberg Bridge 的用武之地。它是一個分為兩部分的解決方案 - 首先，一種以編程方式公開 Gutenberg 塊的方法，以便可以在無頭前端解析和讀取它們。 這篇文章叫做 WPGraphQL Content Blocks。

其次，我們有一個連接器來方便在無頭前端中設置和渲染這些塊。 這是一個名為 Faust WP Blocks 的包。 在這裡，您將看到它如何與這兩個解決方案一起工作的演練。

您網站的基於 React 的後端有其 Gutenberg 塊，這些塊由 WPGraphQL Content Blocks 插件公開。 它將 block.json 內容公開給 WPGraphQL。 它將它提供給名為 WPGraphQL 的插件。

然後它轉到連接器包，它支持塊的定制、發現和渲染。 在我們今天進行技術討論和演示時，實際上將對此進行更多討論。 那麼這會給你的團隊帶來什麼樣的價值呢？

好吧，這是一個端到端的固執己見的解決方案，可以降低複雜性和歧義。 它通過遵循特定的約定來節省開發時間。 它允許組合使用塊和塊模式。 它可以一遍又一遍地重複使用。 現在您已經了解了 React-Gutenberg Bridge 的工作原理，讓我們去 Blake 看看它的實際演示。

布萊克·威爾遜： 謝謝，特蕾莎。 大家好。 我是布萊克·威爾遜。 我是 WP Engine 的一名高級軟件工程師。

我在構建 Faust 的 Faust JS 團隊中。 我今天為您提供了一個非常棒的演示，展示了我們為幫助協調這個 React-Gutenberg Bridge 而構建的兩個組件。 因此，讓我們開始吧。

首先，我將向您展示我在此處設置的內容。 然後我們可以進入實際代碼，看看我們在那裡得到了什麼。 所以對於初學者來說，我有一個在本地運行的 WordPress 網站。

我安裝了一些插件。 所以我得到了浮士德插件。 這有助於促進 Faust JS 站點上的預覽和所有這些好東西。 我有 WPGraphQL，這是將您的 WordPress 站點轉換為 GraphQL 端點所必需的。

然後我得到了 WPGraphQL 內容塊。 所以這是我們為幫助促進這個 React-Gutenberg Bridge 而構建的插件之一。 該解決方案分為兩個主要部分。

因此，我們已經獲得了其中一部分，可以通過 WPGraphQL 以編程方式實際公開 Gutenberg Block 數據，然後另一部分可以在您的 Faust JS 前端上使用它。 讓我們先看看 WPGraphQL 內容塊及其工作原理。

所以我們將進入我們的圖形 IDE。 我在此處設置了此查詢以獲取頁面數據。 所以在這種情況下，我們只是獲取頁面的標題。

所以 GraphQL 內容塊所做的是在您的 GraphQL 模式中公開內容塊類型。 因此，如果我們輸入內容塊，您可以在此處看到，我們將獲取此給定頁面和此頁面上所有塊的信息。 讓我們過去並編輯此頁面並添加一些內容。

所以我們將彈出示例頁面。 你可以在這裡看到我們有一張白紙。 因此，讓我們繼續創建一些塊。 讓我們在這裡創建一些列。

我們將做一個 50/50 的專欄。 讓我們在這一半上添加一個段落，然後在這一半上添加圖像。 所以我的媒體庫中有一張圖片。 讓我們繼續把這個放進去。

你可以在這裡看到，我們有兩列。 同樣，左側是一段，右側是圖像。 所以讓我們更新一下。 讓我們回到 WPGraphQL 內容塊，看看我們得到了什麼結果。

所以你可以在這裡看到，現在我們有兩個內容塊。 這裡的第一個是核心專欄，核心專欄。 然後我們在裡面得到渲染的 HTML。

所以 WPGraphQL 內容塊的偉大之處在於我們也處理 InnerBlocks。 所以你可以在這裡看到，如果我們向名為 flat true 的內容塊添加一個參數，你現在可以看到我們實際上得到了那些列中的所有塊。 所以我們也在為你處理那個案子。

我們得到一個核心欄目，核心欄目，核心段落，核心圖像。 所以所有這些都是以編程方式為您完成的。 現在，您可以在前端使用此塊數據。 因此，讓我們在這裡更深入地挖掘一下。

假設我們想要它的一些屬性。 我們可以使用 GraphQL 中的聯合來使用它。 所以我們將在核心圖像上做，獲取屬性。 例如，假設我們想要標題。

所以你可以看到這裡沒有標題。 讓我們回到示例頁面。 我們將繼續並在此處添加標題。 我的字幕。 更新那個。

如果我們刷新此查詢，我們現在可以看到，我們正在將我的標題作為 WPGraphQL 內容塊中的適當屬性。 所以這是解決方案的第 1 部分。 現在，我們實際上可以獲得我們所有的古騰堡塊數據，並使用它在我們的前端使用它。

因此，讓我們跳轉到 VS Code，我們將看看我們如何處理這一部分。 所以這是我放在一起的 Faust JS 示例項目。 這很簡單。 它基於 Faust 腳手架藍圖，但有一些額外的配置來處理這些塊。

因此，如果我們看一下 JSON 包，您會發現這裡有一些依賴項，一些常用的 Faust 包，例如核心和 CLI。 我們還有 Faust VP Blocks。 所以這是提供我們所有輔助功能的包之一。

我們在 WordPress 上也有一些用於處理樣式等的依賴項。 您還會在這裡註意到我們有這個 WP Blocks 目錄。 所以這是我們前端的所有塊所在的地方，並充當我們在前端使用的所有塊的註冊表。

你可以看到我們有一個 index.js 文件。 這本質上是一個對象，它決定了我們在前端使用的所有塊。 所以你可以在這裡看到，我們有核心段落、核心欄目、核心欄目和核心圖像。

在設置方面，我們將討論兩個主要部分。 一個是 WordPress Blocks 提供者，一個是 WordPress Blocks 查看器。 因此，讓我們看一下它的實際效果。 讓我們首先看一下 WordPress Blocks 提供程序。

這將在 pages_app 中可用。 所以你可以在這裡看到我們有這個組件，這個提供者，WordPress Blocks 提供者。 它接受一個接受塊的配置道具。 所以你可以在這裡看到我們從 WP Blocks 導入塊，這個目錄的索引，我們將它傳遞到配置對像中。

所以本質上，這就是說 WordPress Blocks 提供程序包裝了您的整個應用程序，並為您的整個應用程序提供了所有這些塊的上下文。 現在，讓我們進入 WP Templates 進入我們的單一模板。 你可以在這裡看到我們用內容塊的支持調用 WordPress Blocks 查看器。 所以這是我們從 WPGraphQL 得到的塊數據。

好吧，設置就夠了。 讓我們把它旋轉起來，看看它的實際效果。 所以我要運行 NPM run dev，這將在 localhost 3000 上設置一個開發環境。我們之前處理的頁面是斜杠示例頁面，所以我將訪問 localhost 3000 斜杠示例頁面以查看那些 Gutenberg我們之前設置的塊。

所以你可以在這裡看到，我們的 Gutenberg 編輯器中有相同的塊。 因此，讓我們回到示例頁面的 Gutenberg 編輯器。 你可以看到我們在這裡有兩列，這是我的段落，然後是我們的圖像，它對應於我們在前端的圖像。

所以你可能會說，這看起來很棒，但是我們可以修改樣式嗎？ 我們可以更改字體大小嗎？ 你當然可以。

因此，讓我們回到我們的古騰堡編輯器，對這些塊進行一些修改。 所以讓我們在這里為我們的段落添加背景顏色。 讓我們也將大小更改為大。 對於這裡的這張圖片，讓我們把它弄圓。

讓我們把標題去掉。 我們會更新它。 你可以在這裡看到這些樣式現在適用。 您可以在前端看到它們。

因此，我們真正將您在 WordPress 中不期望的發布者體驗返還給您的無頭 WordPress 網站。 另一件很棒的事情是，現在您可以獲得這些塊的編程數據，您可以使您的 React 組件具有特定於框架的功能，如下圖所示。 現在，我們不僅可以渲染從 WPGraphQL 返回的 HTML，還可以使用該編程數據來創建一個組件，該組件將我們在古騰堡中的所有圖像與下一張圖像一起渲染，從而為我們提供延遲加載、更好的性能和更好的優化圖像總體而言，為我們的用戶創造更好的用戶體驗。

所以這很棒。 我們在 Gutenberg 編輯器中看到的正是我們所期望的，但假設我們添加了一個可能不受支持的組件，或者我們尚未在 Faust 站點中配置的組件。 因此，讓我們繼續在這裡創建一個新組件。 我們將使用表。

我們將做兩行——第 1 行，第 2 行。去更新它。 如果我們在這裡回顧我們的代碼，我們可以看到我們已經定義了四個塊——核心段落、核心欄、核心欄和核心圖像。 我們這裡沒有核心表。

那麼當我們查看這個頁面時會發生什麼呢？ 讓我們來看看。 所以我們將返回 Faust 前端的示例頁面。 你可以看到我們仍然在這裡得到一個包含第 1 行和第 2 行的表格。

那是因為如果您的 Faust JS 項目中尚未定義該塊，我們將對呈現的 HTML 進行明智的智能回退。 這樣，您就不會看到未定義的、空的或根本沒有內容。 至少，您將取回原始呈現的 HTML。

考慮到所有這些，讓我們來看看創建一個塊實際上需要什麼——它實際上是什麼樣子的。 所以我們將在這裡回到 VS Code。 讓我們以核心圖像為例。

所以你可以在這裡看到，這只是一個傳統的 React 組件。 我們稱之為核心形象。 它接受道具，就像任何其他 React 組件一樣。

這里基本上有兩塊。 所以我們得到了實際的 React 組件，它是表示層。 然後我們得到 block.fragments，這是這個塊執行所需的數據。

所以你可以在這裡看到我們正在創建一個片段，核心圖像上的核心圖像片段。 我們得到了這些屬性——我們需要渲染這個塊的屬性。 所以你可以看到我們得到了替代文本、來源、標題、類名、寬度、高度等等。

然後我們可以做的就是將這些屬性應用到我們實際的 React 邏輯中。 因此，此處請求的所有字段都可以在 props 中使用。 所以可以看到props.attributes出來了，就是我們這裡請求的屬性，attributes.alt，attributes.source等等。 因此，這是將塊的所有數據要求集中在同一個文件中的好方法。

這是確保您隻請求您需要的數據，並確保您的請求良好且高效。 在這個示例項目中，我們還有一些輔助函數。 你可以看到這裡有一對——獲取樣式和獲取圖像大小的道具。

所以這些本質上只是從 WordPress 中獲取這些樣式，並將它們組合成 React 可以使用的實際樣式對象。 目前，內聯樣式支持樣式。 您也可以獲得全局樣式表，但我們目前正在努力為 theme.json 提供支持。

因此，Teresa 將在我們未來的路線圖中談及這一點。 但理想情況下，我們可以從 theme.json 獲取所有樣式和填充、邊距等，並將其應用到無頭前端。 考慮到所有這些，讓我們與 Teresa 和我進行快速的技術討論，談談我們目前在這個功能方面所處的位置，以及我們計劃在未來發展的方向。

TERESA GOBBLE： 謝謝你的演示，Blake。 那很棒。 現在讓我們繼續討論一些技術細節，並談談它是如何工作的。 所以我為您準備的第一個問題是，使用 WPGraphQL 內容塊的要求是什麼？

布萊克威爾遜： 是的，是的。 好問題，特蕾莎。 因此，使用該插件的唯一要求是同時安裝 WPGraphQL。 顯然，如果你想讓你的站點與 Faust JS 交互，你可以安裝 Faust JS blocks 包，這將有助於促進渲染和無頭前端的所有好東西。 但是要真正公開塊數據，您只需要 WPGraphQL 和 WP GraphQL Content Blocks 插件。

特蕾莎·戈布爾：太棒了。 區塊數據又是如何收集的？

BLAKE WILSON：是的，所有塊數據都由 WordPress 中使用寄存器塊類型功能的任何塊收集。 因此，幾乎任何您正在使用該功能接口的塊都會顯示在內容塊中。 最棒的是它與 block.json 文件進行中繼，並自動對所有這些字段進行自我描述和自我記錄。 因此，您將文檔合而為一。

特蕾莎·戈布爾：哦，太棒了。 多麼節省時間。 另一件我希望你多談一點的事情是不受支持的塊會發生什麼？ 查詢不受支持的塊時會發生什麼？

BLAKE WILSON： 是的，這是另一個很好的問題。 這裡可能會發生兩種真實情況。 因此，可能存在這樣一種情況，假設您的帖子數據中有一個塊，該塊已從 WordPress 中刪除。

也許是已刪除的第三方塊。 所以這是一個不受支持的塊的例子，它在 Faust 前端和 WordPress 註冊表中都不受支持。 在那種情況下，我們實際上將一個塊返回到稱為未定義塊或未知塊的內容塊，以便您可以在無頭前端中適當地鍵入它。 然後第二部分是如果支持 WordPress 註冊表中的塊，但它在您的 Faust JS 前端尚不支持，在這種情況下，我們所做的就是回退到呈現的 HTML。 這樣，至少，您已經呈現了顯示的 HTML，而不是 null 或 undefined 或任何類似的值。

特蕾莎·戈布爾：哦，太棒了。 這實際上引出了我的下一個問題。 至於無頭分離網站中的第三方插件，您可以通過使用 WPGraphQL Content Blocks 插件來使用第三方插件嗎？ 所有這些如何協同工作？

布萊克威爾遜： 是的，是的。 因此，對於任何第三方插件，回到第一個或第二個問題，只要它們與 WordPress 中註冊的塊類型功能交互，該塊就會自動暴露給 WPGraphQL 內容塊。 因此，只要正在呈現該數據，您就可以在 Faust JS 前端創建塊。 最棒的是假設你有一個輪播的第三方塊。 一旦您在 Faust JS 前端創建了它，您就可以在以後的其他項目中重用它。

特蕾莎·戈布爾：哦，太好了。 這就是可重用性部分的用武之地。有了這個插件，您實際上可以彌補第三方插件與解耦網站無法開箱即用的差距。

此外，如果您現在查看聊天，我們實際上已經構建了一個教程來幫助人們從第三方插件創建一個塊。 所以你現在查看聊天，你將能夠看到它並點擊它。 給它一個書籤。

那麼如何處理塊中的塊呢？ 這真的很棘手。 你能和我們談談那會是什麼樣子嗎？

布萊克威爾遜： 當然，是的。 所以當您查詢名為 flat 的內容塊時，我們有這個標誌或這個參數。 並且接受真值或假值。 因此，當它被提供為 true 時，您實際上會得到該頁面上所有塊的平面數組或平面列表，無論它是列、圖像還是段落。

您將獲得在該頁面上查詢的所有塊的完整列表以及兩個附加屬性。 一個是節點 ID。 這就是那個特定塊的實際 ID。 然後您還將擁有父 ID，它是該塊的父 ID。 所以你可以做的是在你的前端將它重建成一個實際的層次列表，幾乎解決了我們之前在古騰堡看到的內部塊難題。

特蕾莎·戈布爾：太棒了。 所以實際上，有一個選項，在獲取內容塊時，您可以指定在其適當的父子 ID 中返回塊的平面列表？

BLAKE WILSON： 是的，沒錯。

特蕾莎·戈布爾：太好了。 實際上，我們在聊天中還有另一篇教程，同樣，WPGraphQL 內容塊也可以查看該特定功能。 所以我想問你另一個關於樣式部分的問題——使用全局樣式表、內聯樣式，那裡的方法是什麼？ 樣式是如何處理的？

布萊克威爾遜： 是的，是的。 因此，造型可能是我們目前正在努力研究的最大推動力之一。 在我剛剛展示的示例中，它使用了內聯樣式。

全局樣式，也支持全局樣式表。 我認為您將在路線圖中接下來談到這一點。 但理想情況下，我們還希望支持 theme.json 支持，我們可以從 theme.json 中獲取邊距、填充、顏色和所有有用的信息，然後應用它們。 因此，我們將在下一階段的開發中致力於此。

特蕾莎·戈布爾：太棒了。 感謝您引導我們完成這些。 我知道很多人對此感到非常興奮。 那麼我們如何限制發布者使用不支持的塊呢？

布萊克威爾遜： 是的，是的。 所以那裡有一個插件。 這取決於。 如果您使用第三方塊，其中一些已經內置了此功能。

但如果沒有，那裡有一個稱為塊可見性的插件，您實際上可以從發布者的角度切換特定的塊。 因此，假設您有一個尚未在您的 Faust 站點上實施的輪播塊。 您可以安裝塊可見性，並取消選中它，以便發布者在它仍不受支持或處於開發階段時不會使用它。

特蕾莎·戈布爾：哦，太棒了。 這樣插件塊可見性實際上可以切換、隱藏、顯示特定塊？

BLAKE WILSON： 是的，沒錯。 這樣一來，您所支持的塊數量有限，無論是在您的 WordPress 端還是在您的無頭站點中，以便發布者知道，好的，我們可以肯定地使用它，它將在前端。

TERESA GOBBLE：哦，這聽起來確實更乾淨。 嗯不錯。 最後一個問題。 這些前端塊是否對應於發布者的編輯器？

BLAKE WILSON： 是的，非常棒的標註。 所以還沒有。 這是我們將來要努力的事情，但目前，無頭前端支持這些塊。

如果您有一個在 WordPress 中創建的自定義塊，如果您使用的是 NPX 創建塊命令，則您仍然需要在 WordPress 端支持該視圖。 但這是我們正在努力的事情。 我們已經在我們的路線圖中得到它。

特蕾莎·戈布爾：哦，太棒了。 好的。 布萊克，感謝您與我們討論這些要點。 這真的很有幫助，演示也是如此。

讓我們繼續換檔，實際多談談該項目路線圖。 我們實際上有五個階段，其中兩個已經完成——階段 1 和階段 2。階段 1，我們看到了一種方法的實現，可以有效地解構然後重建一個塊。

之後，我們進入了第 2 階段，重點關注 Faust 與 Gutenberg Blocks 的更緊密集成，以確保人們可以訪問其中的不同實用程序和輔助功能。 我們實際上正在進入下一階段，即第 3 階段，我們專注於提供 theme.json 支持和可重用的塊庫，正如 Blake 在我們的技術討論中提到的那樣。

完成後，將進行第 4 和第 5 階段。 第 4 階段的重點是增強現有的開發和編輯體驗，第 5 階段的重點是支持核心 WordPress 之外的更廣泛的生態系統。 我們對即將到來的這些階段感到非常興奮，我們希望您能與我們聯繫並查看我們的博客文章，以了解最新的路線圖。

如果您看一下，您可以在下面的聊天中看到指向我們博客文章的鏈接。 繼續並為它們添加書籤。 好吧，謝謝大家加入我們對 React-Gutenberg Bridge 的討論。 我想在這裡讓 Blake 回到屏幕上，這樣他也可以表達他的謝意，並向我們提供更多信息，告訴我們如果您在此之後有任何揮之不去的問題可以去哪裡。

BLAKE WILSON： 是的，謝謝 Teresa，感謝今天參加本次會議並觀看的所有人。 我們很高興收到一些關於此功能的社區反饋，以便大家開始嘗試。

因此，如果您喜歡它，我們在聊天鏈接中提供了示例項目。 我們在無頭 Discord 的聊天中也有一個鏈接，因此您和其他志同道合的無頭開發者可以加入並討論無頭空間中即將推出的功能和版本。 再次感謝大家。 我們真的很感激。