本文为翻译

原文地址：2023 State of Web Components: Today's standards and a glimpse into the future.

最近，我写了关于如何构建你的第一个 Web Component，以及基本 v1 Web Component 规范的一些历史和解释。但是自从 v1 在 2020 年获得全面支持以来，Web Component 世界发生了更多的事情。未来还有更多计划。让我们来看看使用当前标准构建的一些值得注意的例子，并调查一些在 2023 年及以后制定新的 Web component 标准的工作。

随着 v1 web component 在所有浏览器中的发布，许多公司已经采用并在这些新标准的基础上建立了重要的业务。这里有几个我认为值得注意的例子。

YouTuBe

作为最早采用 Web Component 的网站之一，YouTube 多年来一直使用这项技术构建。检查源代码，您将看到各种自定义元素，从 ytd-video-preview 到 ironic-announcer。

Photoshop

Adobe使用 Lit 将 Photoshop 带到浏览器中。它现在处于测试阶段，如果你是 Adobe 的订阅者，你可以自己尝试一下。从构成应用程序根的 psw-app 到 psw-layers-panel 等 shell 元素，再到 sp-action 按钮等标准小部件，整个过程中都有大量的自定义元素。

MSN, Edge, Bing, VS Code, and More at Microsoft

几年前，微软用基于 FAST 的 Fluent UI Web Components 重新构建了 MSN 体验。这比之前的React版本提高了 30%-50% 的性能。

新的基于 openai 的必应体验也是用 FAST Web Components构建的，如下面的截图所示，是一个开发者最近分享的。

即使是社区用来扩展VS Code的新功能 Webview UI 工具包，也是用 FAST Web Component 构建的。

在过去的三年中，微软内部大约有 1500 个团队和/或项目采用了 FAST Web Component。

Salesforce

在客户关系管理、销售和市场营销领域的业内知名企业之一自动化平台，Salesforce 一直在 Lightning Web Components 上构建组件。

SpaceX

Web Component 现在甚至在太空中得到应用。SpaceX Crew 的显示器正在运行 chromium，广泛的使用 Web Component。

Web标准一直在发展，其中包括 Web Components。自 v1 发布到所有主流浏览器以来的三年里，Web Component 下的特性数量几乎翻了一番。下面是各种已发布的、正在实施的和计划中的 Web Component 相关标准的图表。

让我们逐一查看图示中按照功能划分的六个高级类别中的每一项：组合和作用域、平台互操作性、渲染和性能、样式、包和分发、API 范式

组合和作用域

web component 作用域/封装特性之所以重要，是因为你在学习通用编程时可能已经了解到的所有传统原因:信息隐藏、维护、代码库可伸缩性等。但是当涉及到 web component 时，它们还为 HTML 和 CSS 运行时提供了额外的元数据，可以用来优化绘制和布局。

Shadow DOM

Shadow DOM 是 HTML 中的基本机制，通过它可以限定、封装和组合 DOM 及其相关样式。它是一个多方面的功能，具有许多功能，并且还在继续扩展。

• 命名槽分配(完全支持)：最初的 v1 Shadow DOM 规范提供了一个完全声明性的机制来使用 命名 在Shadow DOM中定义元素组合占位符。组件的使用者可以简单地将slot属性放置在宿主元素的任何子元素上，浏览器将自动“投射”该元素的渲染输出到slot的位置。

• 开放和封闭模式(完全支持)：attachShadow() API 的 mode 选项是 v1 Shadow DOM 规范的一部分。它允许组件作者选择他们首选的封装模式。open 模式使 shadowRoot 可以从主机外部访问，而 closed 模式则拒绝访问。

• 事件重定位(完全支持)：当事件在 Shadow DOM 中的元素中触发时，这些事件会被“重定位”，使它们看起来像是源自 Shadow DOM 宿主。v1 Shadow DOM 规范的这种能力是正确封装内部结构的重要组成部分。

• 手动槽作业(完全支持)：slot 元素上新的 assign API扩展了 v1 版本原始的 slot 分配功能，除了之前的仅声明式插槽机制外，还提供了命令式 API。

• 焦点委托(完全支持)：这个在 v1 之后的特性使 Shadow DOM 能够告诉浏览器，当其宿主元素获得焦点时，它应该将焦点委托给 Shadow DOM 中的特定元素。默认情况下会选择第一个可聚焦元素，但也可以使用 autofocus 属性来覆盖它。

• Cross-root ARIA(接近共识)：即将到来的特性几乎已经与社区和浏览器供应商达成共识，Cross-root ARIA 将大大简化将 Shadow DOM 之外的 ARIA 关键元素与 Shadow DOM 内的元素关联起来。例如，将 Shadow DOM 外部的 label 元素与 Shadow DOM 内部的 input 元素关联起来。这些类型的 ARIA 场景在今天已经有了解决方案，但它们不容易实现。Cross-root ARIA 将大大改善这一点。

• 在Shadow CSS属性定义(共识)中：今天，一些浏览器允许你在 CSS 中使用 @property 语法来定义 CSS 自定义属性。然而，这还不能在 Shadow DOM 中工作。CSS 对象模型总是可以在自定义元素代码中全局使用，但在 Shadow DOM 中以声明形式提供它是一种常用化的改进。这已经达成共识，所以希望我们很快就能看到浏览器普遍支持新的CSS语法。

作用域元素注册表（共识）

在自定义元素的 v1 规范中，所有元素都通过 customElements 全局对象在全局自定义元素注册表中注册。这个新的补充功能使得能够实例化非全局注册表并在其中注册自定义元素。

const myRegistry = new CustomElementRegistry();
myRegistry.define("my-element", MyElement);

这个注册表中的元素仅定义为该注册表所分配的 Shadow DOM。这极大地改善了浏览器中的作用域，使元素定义可以根据需要限定每个 shadow root 的作用域。当它发布到浏览器时，这将是巨大的，打开新的架构可能性。目前，社区和供应商之间已经达成共识，Chromium 正在开发第一个实现。

平台互操作性

web component 最重要的一个方面是它们如何支持组件和平台之间的互操作性。让我们看看这个领域当前和未来的一些特性。

自定义元素

• 自主自定义元素(完全支持)：这个 web component v1 的核心特性允许可以通过注册一个全局变量customElements 的类来继承 HTMLElement 来定义一个自定义元素。基本的生命周期回调和可观察的属性也是规范的一部分。

• 自定义的内置元素(拒绝)：最初，有一个建议允许继承内置元素，例如 HTMLParagraphElement，但 WebKit 的实现人员发现了几个技术问题，因此拒绝了这个规范。它很可能在未来被删除，应该避免。请参阅下面的“自定义属性”以获取可能更好的替代方案。

Element Internals

一个 v1 之后的新 API，ElementInternals，使得自定义元素能够更深入地与现有的 DOM 子系统进行平台级集成。

• Shadow Root 访问：这个简单的添加使组件开发者能够检索 closed 模式元素的 shadow root 实例。否则，具有 closed 模式声明式 Shadow DOM 的元素将无法在运行时访问其根节点。
• 表单相关的自定义元素(完全支持)：这组主要的新特性使自定义元素能够完全参与表单，包括表单验证、提交和重置。
• 默认的可访问性角色、状态和属性(主要支持)：这个新的 API 集合 使得可以通过直接在内部与平台进行通信来设置自定义元素的默认可访问性特性，而不是通过可能被用户无意中删除的宿主元素上的外部属性。目前，除 Firefox 外的所有主要浏览器都支持这个新的 API，对于 Firefox，则提供了一个 polyfill。由于 Firefox 已经实现了 ElementInternals 其他部分的 API，如果他们在不久的将来没有发布这个功能，我会感到惊讶。

组合选择（共识/无规范）

这项改进为 Selection 对象提出了一个新的 getComposedRange() API，它允许范围的开始和结束跨越多个 Shadow Root。它还将提高与当前浏览器处理这些场景的一致性。对于 strawman API 提案 已经达成了普遍共识，但在浏览器继续实现之前，仍然需要一个完整的规范。这不是你在 Web Component 开发的正常过程中可能会遇到的事情。它主要涉及富文本编辑器的实现。

自定义属性（已确定）

虽然此功能不一定是 web component 的一部分，但它与 web component 服务的场景集有很大的重叠。草案建议创建可重用的行为，这些行为可以附加到任何 HTML 元素上，遵循与 web component 类似的模式。例如，想象一下你想要应用到任何 HTML 元素上的 Material Design 涟漪效应。如果你能做这样的事不是很好吗?

<button material-ripple>Click Me</button>

在我为 TPAC 2022 准备的草案提案中，我展示了这样的编程模型:

class MaterialRipple extends Attr {
    // ownerElement inherited from Attr
    // name inherited from Attr
    // value inherited from Attr
    // ...  

    connectedCallback () {
        // called when the ownerElement is connected to the DOM
        // or when the attribute is added to an already connected owner
    }  

    disconnectedCallback () {
        // called when the ownerElement is disconnected from the DOM
        // or when the attribute is removed from a connected owner
    }  

    attributeChangedCallback() {
        // called when the value property of this attribute changes
    }
}  

customAttributes.define("material-ripple", MaterialRipple);

你会注意到，这个模式和生命周期与 Web Components 是一致的。这也为被拒绝的可定制内置自定义元素提案中的 is 属性提供更好、更健壮的替代方案。

渲染和性能

渲染和性能对 web component 至关重要。虽然基础知识今天已经到位，但这仍然是一个探索、辩论和未来创新的活跃领域。

HTML Template 元素（全面支持）

HTMLTemplateElement 及其定义惰性HTML内容的能力是 v1 web component 特性的关键部分。在这个元素出现之前，没有办法声明不会被浏览器激活的 HTML，这使得创建需要按需重复渲染相同 HTML 的组件变得困难。

声明式 Shadow DOM（大多数支持）

Shadow DOM 的 v1 规范只允许通过 attachShadow() JavaScript API 创建 Shadow root。这种对 Shadow DOM 的新增强允许在 HTML 中完全声明 Shadow DOM 内容，而无需使用 JavaScript，为服务器框架开辟了有趣的新可能性。

<host-element>
    <template shadowrootmode="open">
        <slot></slot>
    </template>
    <h2>Light content</h2>>
</host-element>

这个规范重用了 template 元素。不要被这弄糊涂了。它不是模板。它是由 HTML 解析器流到 shadow root 的DOM。

目前除 Firefox 之外的所有浏览器都支持声明式Shadow DOM。 如果需要，这个功能可以用几行 JavaScript 代码来实现。

子节点更改回调函数（提议）

web component 有一个定义良好的生命周期，就像v1规范中为自定义元素所规定的那样，但这并不意味着我们不能在未来扩展生命周期。开发人员面临的常见挑战之一是使 web component 能够响应子节点的添加或删除。现在可以使用 slotchange 事件和 MutationObserver 来实现这一点，但如果有一个像 childrenChangedCallback() 这样的生命周期回调函数会更好，它可以提供改进的性能，简化并与HTML解析器本身集成。目前有一个草案提案，似乎有来自实施者的兴趣。要将这一工作推进到下一阶段，需要一份完整的提案。

模板实例化

虽然 HTML 模板,它还没有一个机制来实例化模板,连接到数据和更新他们当他们依赖数据的变化。这个“模板实例化”的领域有几个部分，每个部分都是独立有价值的。

• DOM部件(提案)：该提案将提供一种在DOM树中特定位置插入或替换内容的标准机制。你可以把它看作是一个低级的使能器，帮助你在现有的web component库和JavaScript框架中创建更高效的模板引擎和批量更新。它不提供响应式解决方案，也不提供模板语法，只提供了定位和更新DOM部分的底层标准基础设施。
• 模板语法(已确定)：一旦定位和批量更新的底层基础设施到位，并且被现有的库成功使用，那么关于语法的争论就会发生。模板语法是一个非常有争议的问题，但人们已经认识到，HTML 应该有一种基本的语言来实现模板语法，即使它只用作其他库的编译目标。
• 响应性(已确定)：DOM部件提供了批量更新 DOM 的标准机制。模板语法提供了创建 DOM 部件的声明机制。剩下的就是一种确定何时应该执行 DOM 部件更新的机制。这时响应式(reactivity)的作用就体现出来了。这是另一个有争议的问题，但已经有一些先例，它通过 web component 的 attributeChangedCallback()。关于这个主题还需要更多的探索。

模板实例化工作类别被分解为上述三个子功能，以便使争议较小的问题能够更早地解决，并为现有库和框架提供一种途径，以利用不那么武断的、提高性能的功能，并为其社区带来更少的阻力。

样式

虽然 Shadow DOM 为样式提供封装，但是有许多 CSS 特性直接与 web component 相关，并且在使用它们的日常工作中非常重要。

使用

当前和未来的一些标准涉及到 web component 如何使用样式来创建 Shadow DOM 的表示。虽然总是可以在 Shadow DOM 中为此创建样式元素，但新标准提供了改进的人体工程学和性能优势。

• 可构造的样式表(完全支持)：你知道吗?在这个标准之前，你无法创建 CSSStyleSheet 实例。这个标准解决了这个问题，所以你现在可以编写代码 new CSSStyleSheet()。这个功能支持在web component中更动态地创建和使用样式，包括跨组件共享样式表。
• 采用的样式表(完全支持)：给定一个 CSSStyleSheet 实例，如何将其与特定的 shadow root 或全局文档关联?这个新标准为 document 和所有 shadow root 实例添加了一个 adoptedStyleSheets 数组。只需将样式表推入该数组，就可以了。
• CSS模块脚本(Chromium)：可构造样式表和已采用的样式表本身提供了创建、共享以及将表与文档关联的原始机制，但这仍然迫使 CSS 本身在 JavaScript 中创建。CSS 模块脚本标准允许使用 JavaScript 模块导入 .CSS 文件，从而在平台上创建 CSSStyleSheet 实例，而不需要在原生 CSS 运行时和 JavaScript 运行时之间来回切换。
• 声明式CSS模块(已确定)：随着 Shadow DOM 和采用声明式样式表,创建了几个草案提议让 CSS 声明模块和以声明的方式将它们与声明性 Shadow DOM。在这个领域还需要更多的探索，但对于 HTML 和 CSS 的未来来说，这是一个令人兴奋的可能性。

呈现

首先,CSS 主要关注呈现。有一些标准扩展了 web component 的样式可能性。

• CSS 自定义属性(完全支持)：自定义 CSS 属性不是 web component所独有的，而是创建组件系统的一个重要方面，它是一个 v1 规范，允许创建可以跨 Shadow Roto 使用的本地 CSS 变量。
• CSS Shadow Parts(全面支持)：CSS 部件允许将 Shadow DOM 中的元素声明为“部件”，并可以从外部使用选择器设置样式。这是通过嵌套场景的 part 属性和 exportparts 属性来完成的。
• CSS 自定义状态(Chromium)：原生元素可以有自定义状态，可以在 CSS 选择器中使用。例如，复选框的“已选中”和“未选中”状态。这个新特性将允许 web component 定义自己的状态。共识已经达成，Chromium 已经发布了第一个实现，可以通过 ElementInternals 访问。它可以在等待其他浏览器赶上的同时进行 polyfill。
• CSS 主题(提案)：虽然丰富的主题可以通过仔细使用 CSS 自定义属性和 CSS Shadow Parts 来实现，但也有可能通过明确地将主题的概念引入 CSS 来简化和改进。
• 开放式 Shadow Root 样式(已确定)：虽然可以使用可构造的样式表和已采用的样式表来在 shadow root 中共享任何全局 CSS，但对于一般的 web 开发人员来说，这可能不是一个直观的过程。关于明确选择允许外部 CSS 进入某些 shadow root 的机制，有一些探索。

打包和分发

到目前为止，我们主要讨论的是与 web component 实现相关的标准。但同样重要的是要考虑如何打包和加载组件。

定义惰性自定义元素（提议）

现在，我们已经能够使用全局 customElements 注册表来定义组件，很快就可以使用自定义注册表。但是，在这两种情况下，在定义组件之前，组件的实现必须已经加载。使用惰性自定义元素，开发人员将能够告诉平台关于元素的信息，但延迟加载它，直到元素第一次出现在文档中时。它可能像这样工作:

customElements.defineLazy(
    "my-element",
    async () => (await import("my-element.js")).default
);

这个规范似乎被大多数人认为是很好的，特别是对于某些体系结构。然而,提议的细节仍在讨论中。

HTML 模块脚本（已确定）

HTML 模块相当于 CSS 模块脚本。有了 HTML 模块提案，模板(和其他 HTML 工件)将可以直接通过 JS 模块系统导入。目前，只有一个草案提案，还有更多的细节需要解决，但这被认为是一个重要的长期增强，特别是考虑到未来可能出现的单文件纯 html web component。

Api 范式

最后一类标准与我之前在这里讨论的所有标准都有所不同。这些标准处理 web component 的基本编程范例。web component v1 主要是一个命令式 JavaScript 编程模型。但也有一些明显的例外，例如声明性的 slot 分配。但在大多数情况下，这是完全必要的。从 v1 版本开始，我们一直在努力引入越来越多的声明性功能。一个典型的例子是声明式 Shadow DOM。一般来说，对所有东西都有声明式和命令式 api 是很好的。但这里的终极目标是最终拥有某种形式的完全声明式定义的 web component，这样服务器就可以向浏览器发送元素定义，这些元素定义可以 100% 地在 noscript 上下文中工作。我们离这个目标还有一段距离，但当我们实现这个目标时，它将从根本上改变客户端和服务器的开发。

标准的工作永远在进行中。事实上，从今天开始，W3C Web 组件社区组正在召开其 2023 年春季面对面活动。就像 TPAC 一样，这是一个机会，供库作者、组件创建者、浏览器厂商等聚集在一起，并花费专门的时间来解决仍需要共识或存在开放问题的规范的细节。我期待在后续的博客文章中向大家更新活动结果。请关注/订阅以确保您获得更新

我希望本次的 Web Components 标准之旅对你来说是有意义的。你看到我们已经走了多远，未来还有什么等待我们，这很有趣。随着 v1 版本的发布，过去几年中已经发布的功能翻了一番，以及即将到来令人兴奋的新功能，现在是成为 Web 开发人员的好时机。