基於組件的主題與 Drupal 的單一目錄組件

Drupal 主題一直是一個長期未被徹底更新觸及的領域。 當然，有大量貢獻的模塊可用於使工作流程更輕鬆一些，但用於創建自定義主題的開箱即用方法或多或少保持不變。 長期以來，人們一直在談論在 Drupal 核心內部擁有某種基於組件的主題機制。 進入單一目錄組件 (SDC) ，通過由傑出的 Drupal 貢獻者——Mateu Aguilo Bosch、Mike Herchel、Lauri Eskola 和 Dave Reid 處理的貢獻模塊，已經討論了很長一段時間。 但現在它已經在 10.1 版本中進入了 Drupal 的核心（目前作為實驗性功能）。

這種基於組件的 Drupal 應用程序主題化方法並不新鮮，但它最終成為了核心。 它為前端開發人員提供了一個全新的前沿領域，讓他們能夠以一種更易於維護且學習曲線最小的方式組織代碼。 在 SDC 中，渲染組件所需的所有文件（Twig、CSS、JS 等）都集中在一個目錄中。 SDC 有可能通過授權開發人員利用最新的前端技術來徹底改變 Drupal 的前端開發，鞏固 Drupal 作為強大且具有前瞻性的 CMS 的地位。

Drupal 當前的主題化方法

處理 Drupal 主題的最簡單方法是將標記添加到模板文件夾內的 html.twig 文件中。 對於樣式和行為，我們根據實體的需要創建 CSS 和 JS 文件，並將它們分別放在 CSS 和 JS 文件夾中。 這包括主題標題菜單、頁腳菜單、塊、區域、各個內容類型及其不同的視圖模式、不同的視圖等。然後在 libraries.yml 文件中聲明這些文件，其中還可以提及依賴項（如果有）。 通過這種方式，它們可以按需加載或在全球範圍內可用。 除此之外，任何預處理邏輯都會進入 .theme 文件，我們有 breakpoints.yml 來幫助進行響應式設計，當然還有 .info.yml 文件，沒有它所有的努力都是浪費。

雖然在我們真正做一些有用的前端工作之前這似乎有很多工作要做，但已經有一些樣板代碼生成器，如drush theme generate ，它打算以交互方式生成主題的文件夾結構並創建一個標準的 drupal 文件夾結構。

儘管上述結構對於啟動一個項目來說已經足夠好了，並且對於一個小項目來說沒有問題，但它可能成為需要集成更複雜的設計系統的企業網站的瓶頸。

1. 事情開始變得非常混亂。 我們看到很多 CSS 和 JS 文件在它們的文件夾中被填滿了。
2. 開發人員努力尋找他們可以重用或擴展的代碼。
3. 諸如代碼重複、代碼散佈在文件中、特異性地獄和 CSS 衝突等問題突然出現。
4. 這通常會導致在後期開發上花費更多的精力，預計最初的開發會在以後有所幫助。

我們在 Specbee 中的主題化方法

在 Specbee，我們已經標準化瞭如何使用我們從頭開發的開源 NPM 工具 Drupal Theme Init 創建主題。 作為 Yeoman 生成器，它可以很容易地與 NPM/Yarn 一起安裝，然後以交互方式幫助生成自定義主題。 Drupal Theme init 的想法是採用一致的方法來按照 Drupal 實踐構建主題文件，並幫助開發人員開始處理主題，而無需在每次開始新項目時都設置文件。 該結構的基本思想是使用 BEM 約定將 SASS 劃分為組件。 每個與實體（如塊、視圖、內容類型等）關聯的 CSS 文件都有自己的 CSS 生成，並通過 twig 模板或預處理附加到該實體。 JS 文件也是如此。 大量使用 libraries.yml 可以幫助我們限制在頁面上呈現的 CSS 和 JS 的數量。

以這種方式設置主題的好處是我們有一個基於組件的主題系統，而不依賴於任何外部庫或插件。 它幫助我們根據要加載到頁面上的組件分離 CSS/JS 庫，這有助於提高性能。 但是，這種方法仍然存在局限性，尤其是當項目規模擴大時。 將組件隔離到原子級別變得有點負擔，因為它需要我們維護具有所需依賴項的 libraries.yml 文件。 此外，我們也沒有簡單的方法可以輕鬆地將設計系統與當前結構進行適當的集成，因為我們也必須在設計系統中自己定義每個組件路徑及其依賴關係，以將組件加載到其中。

什麼是基於組件的主題

雖然 vanilla 方法看起來相當基礎，但最近通過貢獻模塊已經取得了巨大的進步，以獲得更好的方法。 一種流行的方法是將 UI 想像成一組可重用且一致的單元，稱為組件。 在大多數情況下，這遵循原子設計，其中每個組件都被分成更小的構建塊。 UI 模式、組件等模塊！ 或 PatternLab、Fractal 和 Storybook 等組件庫帶來了創新方法，使主題的開發更加流線型和強大。 基於組件的主題比傳統主題有一定的優勢：

1. 最大的瓶頸之一是後端依賴，如果沒有後端工作，前端工作就無法啟動。 這會造成滯後。 使用基於組件的方法，前端可以獨立工作，無需深入了解 Drupal 事物。
2. 只需使用具有所需佔位符的可用設計即可創建組件。 這些佔位符的值可以在後端工作完成後填充
3. 它創建了一個工作流程，我們只是不更改模板文件夾中的標記並根據要求設置樣式。 相反，我們將較小的結構單獨設置樣式，然後將這些較小的單元集合創建為較大的組件，供 Drupal 模板使用。
4. 這有助於隔離地維護與每個組件相關的代碼，並減少產生副作用的機會。
5. 它確認整個應用程序的用戶體驗一致性。
6. 有助於減少設置功能所花費的精力，因為在一個地方所做的更改會反映在使用它的所有區域。

如何在 Drupal 中進行基於組件的主題化

遵循基於組件的開發的主要方法之一是使用 PatternLab，它在很久以前就被引入了。 它最初帶有一個 Drupal 版本，現在已存檔並被基於節點的包取代。 PatternLab 的設置需要安裝一個組件模塊，這將有助於從 Drupal 模板文件夾外的 Twig 文件中獲取標記。 接下來是通過 npm 安裝 patternlab 包，它提供了生成 twig 或基於 mustache 的模板的選項（對我們來說顯然是 twig）。 一旦完成，我們就有了一個現成的推算器風格指南，一些有助於創建風格指南的樣板代碼，以及一個模式文件夾，我們可以在其中根據要求創建組件。 然後這些組件包含在模板文件夾中的 html.twig 文件中。

雖然所有這些步驟都可以很好地執行，但在某些情況下，這有點難以設置並且需要一些學習曲線。 Patternlab 帶來的最大缺點是所有 CSS 都被聚合到一個文件中，然後被轉儲到所有頁面中（有時它包含的 JS 也是這種情況）。 雖然這最初並不重要，因為基本思想是組件的可重用性，但一旦項目增長，這就會開始影響頁面性能。

如何使用 SDC 進行基於組件的主題化

隨著 SDC 的初始版本作為實驗模塊進入核心，人們對它充滿了興奮。 SDC 被吹捧為自引入 Twig 以來對 Drupal 主題的最大改變。 SDC 也不是前端開發團隊的完整解決方案，而是一種組件驅動的主題化方法，具有開箱即用的基本結構。 對於某種工作流程，這仍然可以通過許多模塊進行擴展。 基本思想是與組件相關的所有內容都放在一個目錄中。 這包括組件 Twig 文件、JS、CSS、其他資產和聲明組件屬性的單個模式 YAML 文件。

使用 SDC 的一些直接好處：

1. 與組件相關的所有代碼都在一個目錄中（顧名思義！）。
2. 組件的庫是自動生成的，這可以減少不在 libraries.yml 文件中聲明它的創傷。 雖然我們可能仍然需要將依賴項添加到 component.yml 文件，但這是在一個地方完成的，而不是跳轉到 libraries.yml 文件。
3. 實施 SDC 的學習曲線要小得多。 如果您了解 Drupal 主題化的基礎知識，那麼您需要做的就是啟用該模塊並開始編寫組件。
4. twig 的強大功能（包含/擴展/嵌入）仍然可用，這有助於代碼的可重用性。
5. 由於組件是 YML 插件，因此可以很容易地被 Drupal 發現，並且可以很容易地被具有相同 API 結構的組件交換。
6. 組件也可以通過渲染數組來渲染！
7. 提供了一個很好的機制來集成外部庫以方便設計系統。
8. 隨著組件的組織，其結果是最終產品具有一致的外觀和感覺。
9. 代碼變得更可測試，因為我們有可以獨立測試的單元（讀取組件）
10. 因為我們在組件的 YAML 定義中定義模式，所以模塊可以自動創建表單來填充數據。

雖然它目前作為核心中的一項實驗性功能包含在內，但設置 SDC 非常容易。 假設安裝了 Drupal 10.1.x：

1.啟用實驗性SDC核心模塊。

2.創建或使用自定義主題添加SDC。 為了我們的目的，我們創建了一個名為 Ice Cream 的自定義主題，以 Olivero 作為基本主題。

3. 為了我們的目的，讓我們使用開箱即用的基本頁面。 我通過添加自定義標題字段並對顯示進行一些調整來重新調整它的用途，然後看起來像這樣：

4.模板樹枝文件由基本代碼組成：

5. 在您的自定義主題中創建一個名為components的文件夾。 這類似於我們為 Drupal 模板創建模板文件夾的方式。

6. 目前，基本思路是設置標題和描述的樣式，這在本質上是可重用的。 讓我們創建一個名為 simple-article 的組件。 將有我們需要的 simple-article.component.yml 文件和 simple-article.twig。 除此之外，我們還將為樣式添加 simple-article.css。

7. 讓我們創建simple-article.twig文件。 我們將有一個基本的標記。

8. 使用 https://www.drupal.org/node/3352951 中提到的架構添加simple-article.component.yml文件。 這個想法是定義什麼將是 twig 文件的輸入。 對我們來說它看起來像這樣：

9. 讓我們在simple-article.css中為組件添加一些基本樣式。

10.清除緩存。

11. 胡言亂語！ 該組件現在可以使用了。 但是還是要用的。 否則，該組件將閒置在組件文件夾中。

12. 將此組件包含在所需的模板文件中（這是自定義主題中模板文件夾下的 html.twig 文件），格式為 [theme_name:component-name]。 注意 include 語句，我們在其中添加要在組件中使用的 twig 變量。

13. 組件現在使用我們的新標記和更好的樣式呈​​現。

14. 注意標記。 如果啟用了 twig 調試，我們也會在渲染的 SDC 組件中獲得一些特殊圖標。

就是這樣！

參考

• https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components
• https://www.drupal.org/project/sdc
• https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal

最後的想法

隨著 SDC 的構建方式，圍繞它將會有高強度的開發。 流行的曲目之一是模塊將自動檢測組件並將它們各自的形式插入到 Layout Builder、CKEditor、Paragraphs、Blocks、Fields 等中！ 此外，SDC 現在通過一個名為 CL Server 的貢獻模塊（由 SDC 項目維護者維護）與 Storybook 配合得很好。 已經有其他模塊，如 CL Devel、CL Generator，甚至是圍繞 SDC 構建的 UI Patterns。

這也將幫助我們升級我們自己的主題生成器 (Drupal Theme Init)，我們之前討論過它可以選擇使用 SDC 以及現有的設計系統，最好是 Storybook。 這將幫助任何人立即啟動 SDC 實施，為更好的主題開發鋪平道路。

如果您想在 Drupal 上閱讀更多此類有趣的內容，請立即訂閱我們的每週時事通訊！