在从头开始构建自己的组件库之前，让我们先了解一下不同类型的组件库，以及使用它们的优点和缺点。
？我想特别感谢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 模式和复制指南的所有内容。
一些最著名的设计系统包括：
虽然许多设计系统是特定于公司的，但也有一些设计系统，例如 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。您将学习如何构建和发布可在任何前端框架中工作的组件库。
对我来说，Bootstrap 是第一个想到的。过去，如果您想给您的网站快速上色，您可以将 CDN 链接放到 Bootstrap CSS 文件中，然后立即获得 Bootstrap 外观。在 2010 年代中期，它随处可见。
此类工具的技术范围包括
到
许多其他工具，例如 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 页面时，您将不可避免地问自己，是否构建自己的组件库或使用现有的。
我的第一个想法是：我认为你不应该建立你的图书馆。
我通常倾向于选择经过实战考验的库。特别是具有：
所有这些中最重要的是使用组件库，注意构建可访问的组件。
以组合框为例。它是搜索输入和选择菜单的混合体。如果您自己构建了它，则可能会使其看起来不错，并且可以使用鼠标进行操作。但您还需要考虑：
Konnor Rogers 在 Web + Web 组件领域做出了出色的工作，他在构建可访问的组合框的过程中分享了无数的挫败感。这是他分享的一条这样的推文。
屏幕阅读器支持特别复杂，值得单独列出。为了支持屏幕阅读器，您还需要处理：
顺便说一句，我只能使用 Voiceover，这意味着我很难使用不同的屏幕阅读器来测试这些复杂的 UI 模式。与浏览器一样，屏幕阅读器之间也存在差异。在这篇文章《我们活着吗？》中，斯科特·奥哈拉 (Scott O’Hara) 描述了他们对待生命区域的方式之间存在的差异。
这意味着您（开发人员）也可以选择一个您可以信任的组件库，该库在开发时考虑了可访问性。这就是为什么选择一个拥有强大社区的组件库也很重要。重要的是能够：
最后，同样重要的是，一个优秀的组件库会考虑的不仅仅是组件的美观。对于一个为网络设计的组件库，它应该尽力：
如果我没有吓跑您构建组件库，那么让我自相矛盾并解释一下为什么构建您自己的组件库确实是一件好事。
如果您花时间认真构建组件库，那么您会发现自己是一位更了解浏览器平台、可访问性最佳实践、测试实践等的开发人员。
但它并不止于此，还有一些构建您自己的库的绝佳理由。
对于初学者来说，您可以根据您的需求构建一些东西，并避免现成的组件库可能带来的一些臃肿。您和您的团队需要了解您的最终用户，并且您可以专门为他们构建一些东西。
您还有机会尝试新颖的方法。如果您遇到超利基问题，可能没有组件库可以解决该需求。它可能是一个组件库：
这让您有机会构建适合您需求的东西。然后，当您的需求发生变化或者您更好地了解问题空间时，您就有机会更改和修复问题。
重要的是，这样做您将了解有关网络的更多信息。如果这是您第一次构建组件库，这可能是一个深入研究 HTML 浏览器规范或温习 Web 可访问性知识的机会。这将提高您作为 Web 开发人员的能力，这将对您将来的任何前端项目都有好处。它甚至可以帮助您找到下一份工作。
因此，是否应该构建组件库取决于您的最终目标。考虑以下问题：
根据您的答案，您可以为您的项目做出正确的选择。
感谢您的阅读！如果您有兴趣构建自己的 Web 组件库，请考虑查看我的课程 Component Odyssey。您将学习如何构建和发布可在任何前端框架中工作的组件库。
以上是什么是组件库？您应该构建自己的组件库吗？的详细内容。更多信息请关注PHP中文网其他相关文章！
