為不同上下文製作網絡組件

本文並非講解如何構建Web 組件，Caleb Williams 最近已撰寫了一份詳盡的指南。讓我們來討論如何使用它們，構建時需要考慮哪些因素，以及如何在項目中有效利用它們。

如果您不熟悉Web 組件，Caleb 的指南非常值得一讀，但以下是一些能幫助您快速上手的資源：

• Web 組件——“正確”的方法
• Shadow DOM v1：自包含的Web 組件
• MDN 上的Web 組件
• Awesome Web 組件
• 開放式Web 組件推薦

由於Web 組件現在得到了廣泛支持（這要感謝幕後許多人的辛勤工作）——並且考慮到Edge 將很快切換到Chromium 平台——人們現在將Web 組件視為構建可重用UI 組件的“原生”和平台兼容的方式，以保持設計系統和Web 項目之間的一致性，同時利用Shadow DOM 的強大功能將樣式和邏輯封裝在組件本身中。

這既對也錯。但首先，讓我們了解一下抽象層三角形。

抽象層三角形

從技術上講，我們應該將Web 組件視為我們最喜歡的標記語言HTML 的擴展（是的！）。 Web 組件API 允許我們創建HTML 中不存在的自定義HTML 元素（例如<foo-bar></foo-bar>）。

有人說Web 組件基本上是新的HTML 元素，因此我們應該將它們視為HTML 規範的一部分，因此我們應該遵循其範例、核心概念和用法。如果我們假設所有這些要點，我們會發現我們的組件將存在於Web 平台堆棧的最低層，與HTML、CSS 和JavaScript 並列。框架和庫（如React、Vue、Angular、SvelteJS）在其抽象層上工作，位於其他工具之上，這些工具處於某種“中土世界”，例如StencilJs、Hybrids 和Lit。在這些抽象層之下，我們可以找到我們的基本Web 技術……以及原生Web 組件。我們可以用ALT （ A bstraction L ayer T riangle）圖來表示這個概念：

為什麼這很重要？它有助於我們可視化原生組件之上存在的各個層，並了解它們的使用環境，以便可以針對預期的環境構建它們。什麼是環境？這就是我們的目標。

相同的技術，不同的環境

Shadow DOM 是Web 組件API 中的關鍵因素。它允許我們將JavaScript 和CSS 捆綁到自定義元素中，以防止外部干擾和样式操作，除非我們明確允許。開發人員確實可以遵循一些方法來允許外部CSS 洩漏到shadow root 和組件中，包括自定義屬性以及::part 和::theme 偽元素，Monica Dinculescu 對此進行了很好的介紹。

還需要考慮另一件事：我們正在使用的環境。在我個人構建Web 組件三年後，我可以確定兩種環境：私有環境（如設計系統）和標準環境（如沒有自定義樣式的普通HTML、CSS 和JavaScript）。

在設計組件之前，我們需要了解它們將如何使用，因此確定環境類型是所有這一切的關鍵。最簡單的方法是只針對一個環境，但通過一個小小的CSS 技巧，我們可以為兩者構建組件。

在我們深入了解之前，讓我們看看這兩種環境之間的區別。

私有環境

私有環境是一個封閉的生態系統，它為組件提供自己的樣式，必須按原樣使用。因此，如果我們正在構建一個來自特定樣式指南或設計系統的組件庫，則每個組件都將反映自定義樣式，因此無需每次需要時都對其進行編碼。

JavaScript 邏輯也是如此。例如，我們可以附加一個封閉的shadow root，以防止其他人意外地用querySelector 刺穿shadow boundary。因此，我們可以簡單地選擇和使用任何組件，避免樣式不一致和CSS 衝突等問題。作為作者，您還可以定義一組CSS 自定義屬性（或::parts），這些屬性可用於針對特定用例設置組件的樣式，但這並不是設計系統的重點。

這是一個在私有環境中使用Web 組件的示例。它所有的樣式和邏輯都包含在其shadow-root 中，可以簡單地添加到任何頁面中。

此示例和後續示例僅用於演示目的，並非旨在用於生產環境，因為它們沒有考慮關鍵情況，例如可訪問性和其他優化。

私有環境中的組件很少在該環境之外使用。例如，如果我們嘗試從設計系統（具有其自身強製樣式）中獲取一個元素，我們無法簡單地將其添加到項目中並期望對其進行自定義。您知道Bootstrap 如何根據您的喜好進行主題設置和自定義嗎？這與之完全相反。這些組件旨在在其環境中並且僅在其環境中運行。

標準環境

標準環境可能是最複雜的組件類型，不僅因為環境範圍可以從成熟的框架（如Vue 和React）到普通的原生HTML，而且因為每個人都應該能夠像使用任何其他元素一樣使用該組件。

例如，當公開添加組件（例如添加到npm）時，使用它的人會期望能夠對其進行自定義，至少在某種程度上。

您知道任何帶有其自身演示樣式的HTML 元素嗎？答案應該是“否”，因為元素必須使用CSS 明確設置樣式。對於在標準環境中製作的Web 組件也是如此。單個Web 組件應該可以通過添加類和屬性或其他方法進行自定義。

這是我們在封閉環境示例中看到的相同<todo-list></todo-list>元素，但它是為標準環境設計的。它可以按原樣工作，其shadow root 中沒有任何演示樣式。事實上，它只包含必要的邏輯和基本CSS 以確保其功能。否則，它完全可以像任何標準HTML 元素（如div）一樣進行自定義。

我們為每個環境查看的兩個示例都是使用相同的組件製作的。不同之處在於，標準環境中的組件可以使用外部CSS 進行自定義和選擇。

Web 組件和組合

好的，因此使用Web 組件與使用普通HTML 實際上是一樣的，儘管正如我們所看到的，遵循給定內容的範例和原則非常重要。我們需要注意的是Web 組件的組合。

正如Google Web Fundamentals 所解釋的那樣：

組合是Shadow DOM 最不為人知的功能之一，但可以說是最重要的功能。

在我們的Web 開發世界中，組合是我們如何使用HTML 聲明式地構建應用程序的方式。不同的構建塊（<div> 、<code><s></s> 、<em></em> 、<strong></strong> ）組合在一起形成應用程序。其中一些標籤甚至可以相互配合使用。組合就是為什麼像<select></select>、<details></details> 、<summary></summary>和<video></video>這樣的原生元素如此靈活的原因。每個標籤都接受某些HTML 作為子元素，並對它們執行一些特殊操作。例如，<select></select>知道如何將<option></option>和<optgroup></optgroup>呈現為下拉列表和多選小部件。<details></details>元素將<summary></summary>呈現為可展開的箭頭。甚至<video></video>也知道如何處理某些子元素：<track></track>元素不會被渲染，但它們確實會影響視頻的行為。多麼神奇！組合是我們使用HTML 時通常所做的工作。由於Web 組件僅僅是具有DOM 引用（而不是邏輯容器）的HTML 元素，因此我們應該依靠組合來構建我們的組件和任何子組件。如果您考慮

和<select></select>，您會注意到您聲明式地組合這些元素以獲得最終輸出，並且您有特定屬性可用於主組件（例如[readonly] ）或子組件（例如[selected] ）。對於Web 組件也是如此，如果您正在構建自定義列表，請考慮構建主組件（<custom-list></custom-list> ）和子組件（<custom-li></custom-li> ）。使用<slot></slot>元素，您可以定義子元素將在何處放置，以及在沒有傳遞子元素時將顯示的佔位符內容。

Web 組件和可訪問性

另一件需要考慮的事情是我們稱之為可訪問性的“小”主題。由於我們正在創建全新的HTML 元素，因此我們需要考慮元素的可訪問性，以便提供基本語義角色、任何鍵盤導航以及用戶的操作系統首選項，例如減少運動和高對比度設置。

我強烈建議以下資源作為構建可訪問和包容性組件的參考，如何定義語義標記以及如何實現基本的鍵盤導航。

• 包容性組件
• web.dev 上的“對所有人都有效”
• WAI-ARIA 創作實踐
• WebAIM WCAG 清單

結論

Web 組件是Web 開發中的一項新興技術，因此，就根據其預期用途或最大化用途構建它們而言，並沒有任何明確定義的最佳實踐來指導我們。當您發現自己正在使用它們時，您可能可以從這篇文章中獲得的唯一一點是考慮它們是用於封閉環境還是標準環境，然後問問自己WHI ：

• W ho 將使用此組件？
• H ow much flexibility 這個人應該擁有來對其進行自定義？
• I s 此組件適用於所有人還是特定受眾？