为不同上下文制作网络组件

本文并非讲解如何构建 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（Abstraction Layer Triangle）图来表示这个概念：

为什么这很重要？它有助于我们可视化原生组件之上存在的各个层，并了解它们的使用环境，以便可以针对预期的环境构建它们。什么是环境？这就是我们的目标。

相同的技术，不同的环境

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 元素，因此我们应该依靠组合来构建我们的组件和任何子组件。如果您考虑 <ul></ul> 和 <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：

• Who 将使用此组件？
• How much flexibility 这个人应该拥有来对其进行自定义？
• Is 此组件适用于所有人还是特定受众？