什麼是元件庫？
- WBOY原創
- 2024-08-06 18:35:41370瀏覽
在從頭開始建立自己的元件庫之前，讓我們先了解不同類型的元件庫，以及使用它們的優點和缺點。
？我想特別感謝stephband（Mastodon、Bluesky）的校對和提供回饋。
請注意，這是來自我網站的 X-Post。內容大致相同，但原始貼文中有本文省略的互動片段和影片。
如果沒有音樂專輯怎麼辦？
我是一個超級音樂迷。我最喜歡的消遣之一就是放一張唱片，從頭到尾聽。音樂專輯的概念很簡單，它是由藝術家錄製的一組曲目，被認為是一組完整且連貫的歌曲。
但是如果錄製的音樂不存在怎麼辦？您不能將歌曲錄製到磁帶、CD 或 mp3（或 FLAC，如果您願意的話）中，而只能聆聽藝術家為您現場播放的專輯。你需要去樂隊，請他們設置設備並讓他們從頭到尾播放專輯。他們需要每次都以相同的方式進行遊戲，以確保每個人都有完全相同的體驗。
裂縫將開始顯現。這並不是確保任何對樂團音樂感興趣的人都能聽到的有效方法。如果泰勒絲親自為每個在 Spotify 上收聽過她的歌曲《Fortnight》的人播放她的歌曲，那麼她需要 3,179 年。這還不包括任何飛機旅行。藝術家會感到無聊，甚至可能粗心，導致聽眾的體驗較差。
那麼這跟 Web 開發有什麼關係呢？每次建立 UI 控制項時，您都必須確保其正常運作、健壯且可存取。如果你每次都重寫相同的 UI，你會感到無聊。錯誤會被忽視，從而為最終用戶帶來更糟糕的體驗。
關於我的一點
我已經成為一名 Web 開發人員近 10 年了，我自己編寫了數百個元件，通常多次編寫相同的 UI 模式。我使用了數十個元件庫，並建立了管理儀表板、元件庫、行動應用程式、部落格、figma 外掛程式、VSCode 擴充功能等等。這篇文章將是關於我在哪裡看到元件、函式庫的作用以及開發人員是否應該編寫自己的元件、函式庫的昇華。
什麼是組件？
建立使用者介面時，我們不會每次都從頭開始編寫所有 HTML 標記。我們使用元件（封裝常見 UI 模式的可重複使用建構塊）來編寫 UI。編寫元件可以讓您在單一專案甚至獨立專案中多次使用它。
這裡我寫了一個計數器元件，我已經寫了一次，並在頁面的多個地方使用了它。
<body>
<div class="wrapper">
<counter-button></counter-button>
<counter-button></counter-button>
<counter-button></counter-button>
</div>
<script type="module">
import { LitElement, html } from 'lit';
class CounterButton extends LitElement {
constructor() {
super();
this.count = 0;
}
static properties = {
count: { type: Number }
};
_increment() {
this.count++;
}
render() {
return html`
<button @click=${this._increment}>Count: ${this.count}</button>
`;
}
}
customElements.define('counter-button', CounterButton);
</script>
</body>
我們的教程創建者喜歡演示計數器，就像它們已經過時一樣，但現實世界的應用程式將包含數十種以組件形式編寫的不同 UI 模式。
在本文中，我將把為某些 UI 模式提供樣式的 CSS 規則分組到元件的保護傘下。根據你問的是誰，這個定義可能會變得模糊。
什麼是元件庫？
並非所有組件都是獨立的。將許多元件分組到一個套件（稱為元件庫）是有意義的。
如果您希望您的網站具有特定的外觀或感覺，您可以使用元件庫。有一些元件庫：
- 提供符合設計規範的元件。
- 針對特定 UI 模式提供多種解決方案。
- 使用特定的工具鏈
但它們有不同的形狀和大小。我在定義元件庫時使用的定義如下：
元件庫是一組可重複使用的元件，它們在實用性或外觀（或兩者）方面具有凝聚力。優秀的元件庫將幫助開發人員有效率地實現其 UI 需求，同時為最終用戶提供模範體驗。
元件庫和設計系統有什麼區別
我將在本文後面討論指南和設計系統，因此我將花點時間來消除它們的歧義。很難看出一個事物在哪裡結束，一個事物從哪裡開始，或一個事物包含另一個事物。
設計系統
我將設計系統視為事物的外觀、感覺和行為方式的規範。設計系統可以包含產品、品牌或公司，以確保整套體驗的一致性。一個全面的設計系統將決定從字體系列、字體大小、間距大小、UI 模式和複製指南的所有內容。
一些最著名的設計系統包括：
- 材料設計（Google）
- 基礎設計（Uber）
- 閃電設計系統（Salesforce）
雖然許多設計系統是特定於公司的，但也有一些設計系統，例如 Material Design，全球各地的團隊都可以使用它們來快速地建立熟悉的產品。您可能使用過一些採用 Material Design 原則的產品，但它們肯定無法擺脫基本的可用性問題。
元件庫
對於元件庫來說，它們可能是也可能不是設計系統的程式碼實作。如果您在一家擁有設計系統的公司工作，那麼相應的元件庫（如果存在）很可能與其緊密整合。
例如，Google 的 Material Web 是 Material Design 的 Web 元件實作。基礎 Web 和 Lightning Web 元件也是開源的。
元件庫簡史
UI 元件（或小部件）的概念已經存在很久了。如果您想看看博物館裡的復古使用者介面，請拿一些爆米花並觀看這段 2 個多小時的 1974 年至 1990 年「所有小部件」影片。
從 2000 年代初開始，我們開始看到幫助開發人員建立網路的元件庫。當時的網頁瀏覽器格局與我們現在所見的完全不同。 Internet Explorer 的各個版本完全偏離了該規範，考慮到 IE 當年擁有的巨大市場份額，這尤其成問題。 Internet Explorer 6 因開發起來很痛苦而聞名。主要是因為它對盒子模型的實現不正確，並且缺乏 CSS2 支援。
？到目前為止，Internet Explorer 支援“怪異模式”，允許開發人員編寫非標準 HTML 和 CSS，以安撫不支援標準的舊版瀏覽器。
幸運的是，當我認真開始 Web 開發時，其中許多問題都得到了解決。 到目前為止，仍然有一些函式庫可以讓編寫具有跨瀏覽器支援的複雜介面變得更加容易。 jQuery UI，我使用的第一個元件庫，支援手風琴和其他小部件。但瀏覽器不斷發展，我們現在有了使用詳細資訊和摘要元素來實現此手風琴模式的本機方法，2020 年所有瀏覽器中都將提供這些元素。有了這些元素，您無需 JavaScript 即可建立互動式手風琴。
與 2009 年相比，這些元素尚未在任何瀏覽器中實現。它需要相當多的 JS 才能工作。如果您想了解 15 年前 Web 開發人員如何實現手風琴，請查看 jQuery UI v1.7 原始程式碼，並按 CTRL+F「手風琴」。
在接下來的幾十年裡，網路的能力不斷增強。更強大的設備意味著更強大的瀏覽器。更強大的瀏覽器意味著 Web 應用程式變得更加雄心勃勃。開發人員的回應是創建工具來幫助我們建立這些應用程序，允許我們使用構建塊（即組件模型）創建 UI。我們看到這些基於組件的框架的激增。我說的是 Angular、React 和 Vue。每個都有自己豐富的組件庫生態系統。
有一個合理的論點，即存在過度修正，並且前端景觀現在已經過度飽和，工具對於大多數人的需求來說太強大，但我們不要這樣做。
此版本在原始帖子上添加了互動式片段
怎樣才是一個好的元件庫？
建置元件庫的挑戰在於它們不是一勞永逸的交易。許多最受歡迎的圖書館已經存在多年，並進行了大量的研究、使用回饋和貢獻，才達到了現在的水平。
我發現一個好的元件庫往往有以下特點：
- 它了解目標開發人員的問題並且很好地解決這些問題
- 它有很棒的文檔
- 確保最終使用者獲得良好的體驗
- 它很強大，適合適當的輸入模式和設備。
另一方面，辨別元件庫是否不好的一種方法是它是否不考慮可訪問性、是否具有不一致的API、幾乎沒有或沒有專案管理，或者沒有清晰一致的文件.
使用元件庫有什麼好處？
我們知道一個好的元件庫是什麼樣的，所以讓我們看看如何讓您和使用者的生活變得更好。
元件庫節省您的時間
如果您的專案期限緊迫，保持高效率就很重要。但效率不應以打造強大的網路體驗為代價。使用組件庫可以讓您花更少的時間重新發明輪子，而將更多的時間專注於更精細的細節。
元件庫讓您和您的使用者更快樂
我們不會因為重複性工作而受到激勵。我們喜歡技術挑戰，重複編寫相同的元件並不是一個有趣的挑戰。我們已經討論過當我們感到無聊並讓錯誤溜走時會發生什麼。
如果你想從頭開始實作一個對話框元件，你需要：
- 正確處理焦點陷印
- 讓頁面的其餘部分變得惰性
- 正確定位對話框
- 確保它與輔助技術配合使用
記住並實現上述內容需要花些功夫，但如果弄錯了，可能會導致你的介面實際上無法使用，如果你錯誤地處理焦點，就會出現這種情況。
透過使用專為最終用戶建立的元件庫，您可以防止引入損壞體驗的風險，同時花費更少的時間重建相同的元件。
元件庫帶來一致的體驗
如果您在一家擁有多個不同 Web 應用程式的公司工作，他們通常會遵循一組準則。這些指南可能規定要使用的調色板、版式的大小或 UI 元素的外觀和行為方式。
但是，如果您重寫元件，則會增加應用程式偏離樣式指南的可能性。透過擁有元件庫，您可以根據品牌指南更輕鬆地審核元件的 UI，以便無論在何處使用它們，它們看起來都很棒。
Uber 有幾個不同的應用程式共享相同的使用者介面元素。我幾乎可以肯定他們在這些應用程式中使用相同的元件庫。這樣，每個新應用程式幾乎都可以保證遵守該品牌的指導方針。
使用第三方元件庫有哪些缺點？
我上面提到的好處與您使用自己的元件庫還是第三方元件庫無關。如果您或您的團隊決定不想建立庫，而是依賴第三方，那麼值得考慮以下事項。
供應商鎖定
透過選擇元件庫，您選擇的合作夥伴將極大地影響您編寫前端程式碼的方式以及介面的外觀和行為。
前者會對你產生很大的影響，後者會對你的最終用戶產生很大的影響。使用元件庫會將您鎖定在該元件庫的標準中。
該程式庫可能會在主要版本中引入巨大的破壞性更改，這可能需要專門的開發時間和大量測試以確保不會引入嚴重的回歸。
幾年前，我使用 React Admin 為內部部門建立了一個複雜的管理儀表板。該庫提供了一套專門用於獲取和顯示複雜數據的元件。由於我們當時的應用程式嚴重依賴 React Admin，因此在主要版本之間進行升級非常具有挑戰性，特別是因為 React Admin 使用的許多內部工具已被其他工具取代。變化面巨大，我們花了很多時間升級並標記我們發現的問題。
我認為從長遠來看，建立我們自己的解決方案不會為我們節省任何時間，但這種供應商鎖定值得考慮，尤其是在全力使用工具之前。
程式碼膨脹
令人震驚的是，具有大量元件的函式庫往往是使用大量程式碼編寫的。您在安裝依賴項時下載的程式碼，以及傳送給最終使用者的程式碼。
現代工具可以更輕鬆地執行捆綁最佳化，例如透過 tree-shaking 來刪除未使用的程式碼，但不能保證您會刪除使用者不需要的所有程式碼。
除非您深入研究正在使用的程式庫，否則您可能不知道它們正在匯入的所有單獨的套件。您最終可能會產生數百個不必要的依賴項。 e18e 社群的人們一直在努力揭露這個問題，同時也解決它。
其中許多問題也可以與滾動您自己的元件庫有關。最大的區別是您對元件庫擁有管理權。您可以定義它如何解決您的特定問題，並且您可以控制改進其缺點。
元件庫可以採用的不同形狀
萬維網的最初提議是一個改善歐洲核子研究中心研究人員之間溝通的工具。該提案概述瞭如何共享文件以及如何透過使用超文本相互連結。這是網路的基本基石，我們仍然使用簡陋的 。標籤用於在網路上的其他 HTML 文件之間進行連結。
但是在過去的幾十年裡，網路的範圍不斷擴大，我們用來瀏覽網路的瀏覽器已經成為了自己的野獸。現今的瀏覽器可以實現強大的創意表達形式，以及類似本機的軟體的運作。
有數百種不同的解決方案，有些是通用的，有些是超利基的，但是為您的下一個專案找到合適的工具需要一個複雜的決策過程，可能如下所示。
這不是所有用例或元件庫類型的完整列表，但它說明了元件庫在以下方面的差異：
- 涉及的技術。
- 它們提供的抽象層級。
- 他們解決的問題。
讓我們來看看一些最常見的元件庫類型
？附註：如果您有興趣建立自己的 Web 元件庫，請考慮查看我的課程 Component Odyssey。您將學習如何建置和發布可在任何前端框架中運作的元件庫。
實用類別庫/CSS 樣式指南
對我來說，Bootstrap 是第一個想到的。過去，如果您想為您的網站快速上色，您可以將 CDN 連結放到 Bootstrap CSS 檔案中，然後立即獲得 Bootstrap 外觀。在 2010 年代中期，它隨處可見。
此類工具的技術範圍包括
- 單一 CSS 檔案 (Pico)
到
- 根據您的配置產生 CSS 類別的工具鏈 (Tailwind)
許多其他工具，例如 Open Props，介於兩者之間。
現成的元件庫
如果您正在建立互動式 Web 應用程序，您可能只想獲取一套看起來很棒且功能良好的組件。有許多現成的元件庫可以為您提供所需的一切以及更多。
無論您使用哪種框架編寫應用程序，都可能有一組外觀精美的組件供您使用。
另一個很棒的元件庫是 Shoelace，它提供了數十個完全互動式和完全樣式化的元件。
像 Shoelace 這樣的函式庫特別有趣的是，它是使用 Web 元件（瀏覽器編寫元件的內建方式）建構的。使用 Shoelace 等工具建立 UI 可以為您帶來額外的好處，即能夠在不同的前端框架中使用它們。這是我過去談過的事。
這是 Vue 和 React 中使用的相同 Shoelace 元件。
無樣式組件
根據您項目的規格，您可能無法使用現成的工具。您的設計規格可能非常具體。
我看過團隊在第一次出現摩擦跡象時就滾動組件。在一個手動資料選擇器的案例中，導致了更糟糕的使用者體驗。回想起來，使用無樣式的元件庫可以為團隊提供外觀方面的靈活性，同時確保時間
這就是為什麼你可以找到一個庫，它提供完全無樣式的元件和靈活的樣式掛鉤。如果它是一個好的函式庫，它也會處理所有這些複雜的互動。這是兩全其美的情況。
如果您想超越瀏覽器提供的樣式掛鉤，很容易搞亂複選框，除非您使用各種裝置和輸入模式進行測試。
原始文章有一個視頻，展示了我使用屏幕閱讀器與不同的複選框實現進行交互
Radix 是一個流行的函式庫範例，但它是使用 React 建構的。
其他類似的元件庫的範例是 Lion 和 HeadlessUI。
複製可貼上的元件庫
有些開發者可能想要兩全其美。他們可能想要一個由受信任的第三方函式庫建構的元件，同時還可以完全控制標記、樣式和功能。像 ShadCN 這樣的函式庫允許這種工作流程，允許開發人員將元件定義複製並貼上到自己的專案中，從而有效地讓他們擁有元件。
為什麼沒有一個元件庫來統治所有這些呢？
此時，可能很清楚為什麼不存在這樣的單一元件庫了。我們對不同組別的組件庫進行了非詳盡的研究。
然而，有一場引入「全球設計系統」的運動，這是由布拉德·弗羅斯特（Brad Frost）帶頭的概念。
在公告中，Brad 概述了在他參與的數百個專案中，許多UI 控制在這些不同的專案中表現（或應該表現）相似，但開發人員在每個專案中重新實現相同的東西。這導致了大量時間和精力的浪費，以及專案之間的不一致。這也擴展到現有的元件庫。您會發現 React Aria 中組合方塊的鍵盤行為與 ShadCN 中組合方塊的鍵盤行為不同。
原始文章有一個視頻，向我展示了使用鍵盤與不同組合框實現進行交互
Brad Frost 提出了一個全域設計系統作為一組 Web 元件，幾乎所有前端專案都可以採用它，以確保 HTML 中尚未提供的控制項的功能基準。
開放 UI 內正在進行討論，看看如何在未來幾年內開始成形。
您應該建立自己的元件庫嗎？
本文對元件庫進行了廣泛的探討，有了所有這些背景，當您盯著下一個大專案的空HTML 頁面時，您將不可避免地問自己，是否建立自己的元件庫或使用現有的。
我的第一個想法是：我認為你不應該建立你的圖書館。
我通常傾向於選擇經過實戰考驗的庫。特別是具有：
- 已在數千個項目中使用
- Discord 或 GitHub 中的強大社區
- 很棒的文件
- 高度重視可訪問性
- 利用所選框架的優勢
所有這些中最重要的是使用元件庫，注意建立可存取的元件。
以組合框為例。它是搜尋輸入和選擇選單的混合體。如果您自己建立了它，則可能會使其看起來不錯，並且可以使用滑鼠進行操作。但您還需要考慮：
- 跨瀏覽器支援
- Tab 和焦點行為
- 螢幕閱讀器支援
- 處理搜尋結果非同步載入的狀態
Konnor Rogers 在 Web + Web 組件領域做出了出色的工作，他在構建可訪問的組合框的過程中分享了無數的挫敗感。這是他分享的一則這樣的推文。
螢幕閱讀器支援特別複雜，值得單獨列出。為了支援螢幕閱讀器，您還需要處理：
- 即時區域
- 互動式控制項
- 所選商品
- 不同螢幕閱讀器之間的支援
順便說一句，我只能使用 Voiceover，這意味著我很難使用不同的螢幕閱讀器來測試這些複雜的 UI 模式。與瀏覽器一樣，螢幕閱讀器之間也存在差異。在這篇文章《我們活著嗎？ 》中，斯科特·奧哈拉 (Scott O’Hara) 描述了他們對待生命區域的方式之間存在的差異。
這意味著您（開發人員）也可以選擇一個您可以信任的元件庫，該庫在開發時考慮了可訪問性。這就是為什麼選擇一個擁有強大社區的元件庫也很重要。重要的是能夠：
- 查看其他人針對給定庫標記的錯誤和問題
- 建議（甚至貢獻）對此類庫的改進和更改
- 與社區成員討論想法，並與社區的活躍成員甚至維護者本身建立工作關係
最後，同樣重要的是，一個優秀的元件庫會考慮的不僅僅是組件的美觀。對於一個為網路設計的元件庫，它應該盡力：
- 遵守網頁內容無障礙指南 (WCAG)
- 確保組件可以跨不同的輸入方式（觸控、鍵盤、螢幕閱讀器）
- 確保這些組件可供有額外要求的人使用，例如那些患有前庭疾病、視力障礙或手部骨折的人。
實際上，建立自己的元件庫是一件好事
如果我沒有嚇跑您建立元件庫，那麼讓我自相矛盾並解釋為什麼建立自己的元件庫確實是一件好事。
如果您花時間認真建立元件庫，那麼您會發現自己是一位更了解瀏覽器平台、可訪問性最佳實踐、測試實踐等的開發人員。
但它不止於此，還有一些建立自己的函式庫的絕佳理由。
對於初學者來說，您可以根據您的需求建立一些東西，並避免現成的元件庫可能帶來的一些臃腫。您和您的團隊需要了解您的最終用戶，並且您可以專門為他們建立一些東西。
您還有機會嘗試新穎的方法。如果您遇到超利基問題，可能沒有元件庫可以解決該需求。它可能是一個元件庫：
- 以特定方式視覺化資料
- 擁有鮮明而獨特的視覺形象
- 基於新框架建構
這讓您有機會建立適合您需求的東西。然後，當您的需求發生變化或您更好地了解問題空間時，您就有機會更改和修復問題。
重要的是，這樣做您將了解更多有關網路的資訊。如果這是您第一次建立元件庫，這可能是深入研究 HTML 瀏覽器規格或溫習 Web 可訪問性知識的機會。這將提高您作為 Web 開發人員的能力，這將對您將來的任何前端專案都有好處。它甚至可以幫助您找到下一份工作。
因此，是否應該建立元件庫取決於您的最終目標。考慮以下問題：
- 我想更了解瀏覽器嗎？
- 我想快速建造一些東西嗎？
- 我想讓它可供盡可能多的用戶使用嗎？
- 是否存在可以解決我目前問題的函式庫？
根據您的答案，您可以為您的專案做出正確的選擇。
感謝您的閱讀！如果您有興趣建立自己的 Web 元件庫，請考慮查看我的課程 Component Odyssey。您將學習如何建置和發布可在任何前端框架中運作的元件庫。
以上是什麼是元件庫？的詳細內容。更多資訊請關注PHP中文網其他相關文章！