我为什么使用 Web 组件 - 我的用例

首先声明，我不是博主，也不是任何技术的倡导者，也不会在活动或会议上发言。所以请谅解我首次尝试写作。希望我表达清晰。

我想谈论一些实际的用例和场景，在这些用例和场景中我发现 Web 组件是最好的解决方案。

每当我看到关于 Web 组件的讨论时，通常都会转向 API 设计和与框架的比较。我不会为这个 API 辩护，因为它不是我写的。我也不会批评它，因为其他人在这方面做得更好。

问题解决了吗？

人们常说组件是一个已解决的问题——看看所有这些有宗教信仰的框架！

现在，如果你正在开发一个应用程序，比如一个图书推荐应用程序——你应该用任何你熟悉的框架来编写它。或者只用 Web 组件，或者用 2000 年左右的 HTML + JavaScript 编写。都可以。你可以使用任何你想要的组件系统，只要它符合你的目标。

但是，如果你想编写一个真正可共享的富组件，没有其他可用的模型。你不能在 Svelte 中使用 React 组件，也不能在 React、Vue 或 Nimbus3000 中使用 Svelte 模块。

我的用例

我将讨论一些我认为使用 WebComponents 是正确的实际场景。这里的核心主题是可共享和跨框架。

1.可嵌入前端（MicroFrontends？）

我帮助许多网站提升网站的互动性和各种花哨的功能。这些网站并非由那些高大上的开发者维护——比如博主、艺术家、内容创作者或小型企业。其中一些网站流量巨大（每月 1 亿页面）。我们有一个数据引擎，可以扫描和监控他们网站上的数据，并将这些数据反馈到可嵌入的前端，从而提升网站的互动性。以下是一些示例：

• 根据用户定制的实时搜索
• 启动与用户感兴趣的内容相关的动态游戏
• 相关内容的无限列表

这些网站大多基于 WordPress、Squarespace 以及使用 React 和 Vue 渲染的框架。我们的前端以 WebComponents 的形式注入。
发布者可以随意添加组件。无需 npm 或复杂的构建流程。

将其置于 Web 组件中，可以屏蔽其内容，不受其所使用的主题或系统上运行的其他框架的影响。其中一些组件会与主页面上的其他内容进行交互。它们必须具备高性能和小巧的尺寸。

这些发布者通常具备基本的 HTML 知识，他们将其添加到他们的内容中，就像添加图像或视频一样。

2. 复杂的小部件

上面的例子是一个非常定制的解决方案，但也有一些开发人员创建了通用的小部件。

<model-viewer>就是一个很好的例子。它被广泛使用，比如 NASA 和 Shopify。我不知道 Shopify 用的是什么框架（而且它可能和 NASA 不一样），但有了模型查看器这个 Web 组件，他们找到了解决方案。

所谓的“设计系统”也是如此。例如， Ionic 的组件最初是作为 Web 组件开发的，后来也被包装到不同的框架中，例如 React、Vue。

3. 不断发展的 HTML

HTML5 规范中添加了各种各样的新标签，比如<video>。它永远不会添加任何新标签吗？一种观点认为 DOM 很糟糕，所有新元素都应该定义一个全新的组件格式。或者更现实的说法是，它可能会添加更多标签——人们已经知道如何使用标签了。

正在考虑的新标签之一是switch。为了测试可能的实现，Chrome 将其作为 Web 组件发布<std-switch>，因为它本质上扩展了内置元素。当不在 Chrome 上使用时，Web 组件可以作为后备模块加载。扩展现有的底层元素模型有其价值。

此类别中的个人故事：我研究生院的一个朋友尝试在某个网页上使用 MathML。（他们不是开发者。）Chrome 目前不支持 MathML。他们可以使用某种库来渲染它。我把MathML 实现为 Web 组件，这是一个有趣的项目，他们只需稍加修改就可以在 Chrome 中使用。

造型

从某种程度上来说，该平台中并没有 Web 组件。目前有一些独立的规范，例如自定义元素和 ShadowDom，它们是主要的规范。此外，还有更多用于导入 CSS、HTML 和 JSON 的规范正在开发中。

在开发者看来，所有这些单独的规范都有其自身的优点，也存在各自的设计缺陷。它们可以单独使用，不必全部都变成Web 组件。

组件中不在 ShadowDOM 内的部分可以使用全局样式表进行样式设置，而 ShadowDOM 内的部分则被隔离。这在我重点讨论的可共享组件场景中尤其有用。

开发者体验

人们对 WC 的一个常见抱怨是它们代码太冗长。它没有绑定之类的。就像我之前说的，我不想讨论现有 API 和 DX 的优缺点。

我确实认为，如果你想的话，使用框架和库是合理的。我的意思是，你已经在用了，有时甚至会编译。有些人认为他们应该完全不使用外部库，这是一个很好的目标，值得努力。但事实上，对于大多数开发者来说，使用库要容易得多。所以，不要再把 DOM API 和可以编译成 DOM API 的框架 API 进行比较了。我认为辅助库非常棒。我们已经在许多其他 Web 技术中使用它，例如 Web RTC、Workers 等等。

如果你需要的话，有一些很棒的辅助库可以帮助你处理 WC。例如：Lit Element、Stencil和Haunted（如果你喜欢 Hooks）。

使用 LitElement 的示例：

@customElement('my-counter')
class Counter extends LitElement {
  @property({ type: Number }) count = 0;

  render() {
    return html`
      <div>${this.count}</div>
      <button @click="${() => this.count++}">Increment</button>
    `;
  }
}

使用 Haunted 的示例：

function Counter() {
  const [count, setCount] = useState(0);
  return html`
      <div id="count">${count}</div>
      <button type="button" @click=${() => setCount(count + 1)}>Increment</button>
  `;
}
customElements.define('my-counter', component(Counter));

不是你的用例

我的用例和你的用例不一样。这些对你来说可能毫无意义，但我想你可能有兴趣从不同的角度听听我的观点。