隨著區塊編輯器不斷發展其內容管理能力，對自定義欄位的支援不足已成為使用者和開發者的主要障礙之一。雖然 WordPress 中的自定義欄位仍然被廣泛使用，但在區塊編輯器中，它們被降級為螢幕底部的抽屜，並沒有像許多人希望的那樣被深度整合。隨著即將到來的區塊繫結 API，情況將發生非常好的改變。
什麼是區塊繫結 API？
解釋區塊繫結 API 的最佳方式之一是從一個像 WooCommerce 這樣的外掛開始。
想象一下，您正在構建您的 WooCommerce 商店，並使用塊設計您站點的主頁。您正在使用查詢迴圈來顯示您最暢銷的產品，這意味著您將使用許多塊來獲取關於您的產品的重要自定義資訊-產品描述、圖片、畫廊、新增到購物車按鈕等等。
現在，WooCommerce 需要為每個單獨的內容部分建立和管理自定義塊。這是大量重複的程式碼和技術開銷。而且，隨著新的設計工具被新增到區塊編輯器中，開發團隊必須在每次釋出後都返回並確保他們的自定義塊可以正確支援新功能。如果他們可以使用核心塊-如段落、標題或按鈕塊-並告訴 WordPress 將該塊 「連線」 到產品資料，這不是更有意義嗎？
這只是區塊繫結 API 承諾的一個例子，自定義欄位只是許多用例之一。一旦奠定了基礎，這個功能可以擴充套件到在區塊編輯器中相對難以管理的所有型別的資料，從填充文章和站點資訊 （如作者名稱或特色影象） 到幫助同步模式變得更加健壯。
動態資料能節省時間和資源嗎？
為了瞭解更多關於區塊繫結 API 的資訊，我聯絡了 Pods 框架的首席開發人員 Scott Kingsley Clark，他是 WordPress 核心中 Fields API 功能專案的主要推動力。 Fields API 提案圍繞 WordPress 中的類似問題：我們如何幫助開發者避免一遍又一遍地編寫相同的程式碼？
這就是像 Pods 和 Advanced Custom Fields 這樣的工具要解決的問題。它們使開發人員免於在每個專案上從頭開始編寫相同的自定義文章型別程式碼、自定義設定螢幕和自定義欄位輸入。 Scott 指出了他的工作和 WooCommerce 之間的聯絡，指出許多 Block 繫結 API 的貢獻者實際上也是 WooCommerce 的貢獻者。
「新的 WooCommerce 產品編輯螢幕由塊驅動，」Scott 解釋道，「你可以完全看到他們在該功能上的每個版本的發展，因為他們抽象了更多的內容，並開始找到合併的方法，而不是 『每個具體的欄位都必須是他們自己的具體塊』，這一直在阻礙他們。」
Scott 一直在提供有關 API 的反饋，並正在努力確保 Pods 框架在 3 月 26 日 WordPress 6.5 釋出之前準備好了整合。
我還詢問了 Advanced Custom Fields 的產品經理 Iain Poulson，未來我們是否會看到 ACF 的自定義欄位使用此 API 與核心塊連線。
「ACF 團隊在過去幾個月裡一直在密切關注區塊繫結 API 的開發，」Iain 說道。 「我們目前正在探索構建我們自己的繫結源，以允許使用者使用 ACF 欄位值繫結到塊屬性，並希望很快就能有一個工作原型。」
最初，外掛 （如 Pods 和 ACF） 的自定義欄位有望直接使用，但一些最後一刻的安全清理意味著任何具有更自定義方法的外掛都需要構建與 API 的自己的整合。
「我們注意到今天 WordPress 核心合併了一個 PR，這很可能意味著 ACF 欄位將無法在沒有此工作的情況下繫結，」Iain 本週早些時候告訴我。 「我們預計 WordPress 未來的版本將發生重大變化，將有新的連線 UI 和從繫結本身更新值的能力，我們非常願意為 ACF 使用者帶來所有這些功能，並將與 WordPress 核心團隊合作確保我們可以做到。」
瞭解到主要外掛投入到這個新的 API 中是令人興奮的。這裡還重要的是要對 API 的期望保持適度。在將其深度嵌入開發者工作流程之前，還有漫長的路線圖和許多實驗需要進行。
這是一個沒有 UI 的 API 嗎？
儘管 WordPress 6.5 版本包含了核心中的區塊繫結 API，但我們還不會立即看到此功能的實際使用者介面。這仍然是一個 「底層」 功能，但其包含意味著外掛和主題開發者可以開始構建在其之上。
在 6.5 中，區塊繫結只能以兩種方式之一使用，兩種方式都涉及少量程式碼：
- 您可以採用 WordPress 開發者部落格中提倡的方法：將區塊編輯器切換到 「程式碼編輯器」 模式，並直接向塊 HTML 新增繫結後設資料。
- 您可以利用塊變體 API，向核心塊新增已經包含繫結後設資料的版本。這將需要在主題或外掛中放置一些 JavaScript，但好處是，一旦進入內容編輯器，您的變體將顯示為其自己的塊在塊插入器中。
當前的實現僅支援四個核心塊 （段落、標題、按鈕和影象），事實上，這四個塊是最常用的內容塊之一，並且將構成絕大多數用例，儘管其他塊也計劃中。對於終端使用者來說，這意味著使用此 API 的任何塊將與他們已經熟悉的核心塊的功能完全相同，這對可用性是一種勝利。
專案的跟蹤問題清楚地表明，區塊繫結 API 的無程式碼介面即將推出，一些概念驗證示例已經在探索中。透過採用這種以 API 為先的方法，核心團隊可以看到功能在實際使用中的情況，然後再決定是否改變區塊編輯器，並且在外掛團隊構建自己的整合時可能會獲得一些啟發。
如果您是終端使用者，您可能暫時不會注意到任何新的東西。但如果您是外掛或主題開發人員，現在可能是探索區塊繫結 API 並利用這個省時功能的時候了。
發表回覆