五分钟带你了解 Web Components

本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

在前端快速发展的今天，组件贯彻着我们日常开发的方方面面，不管是针对业务封装的业务组件，还是项目中依赖的第三方基础 UI 组件（Ant Design、Element、Iviewui...），亦或是依赖的前端框架（Angular、Inferno、Preact、Vue、React、snabbdom、virtual-dom...），它们都贯彻着「组件化」的概念，而这一切「组件化」都是「高内聚、低耦合」思想下的产物。

高内聚、低耦合，是软件工程中的概念，是判断软件设计好坏的标准，主要用于程序的面向对象的设计。它的考量标准是类的内聚性是否高，耦合度是否低。目的是使程序模块的可重用性、移植性大大增强。

「组件化」开发已然成为前端主流开发方式，因为「组件化」开发在代码复用、提升团队效率方面有着无可比拟的优势，现在流行的 Vue、React、Angular 等等框架都是组件框架。所以毫不夸张的说 「组件化将会是前端的发展方向」。

有读者可能会疑惑，Vue、React、Angular 这些前端框架也是组件？答案是肯定的，前端框架的本质也就是抽象的组件。从结果导向来看，无论什么框架归根结底最后都会编程成 Js、Css、Html，因为只有这样才能被浏览器“认识”。在框架的设计思想层面上，「组件化」也只是进行一些功能的抽象和代码的隔离。

就当下而言，使用这些框架也会给我们带来一系列问题，例如：

为了解决这些问题，各种解决方案层出不穷，其中 Web Components 就是其中关键的一环。

Web Components 是一套不同的技术，允许您创建可重用的定制元素（它们的功能封装在您的代码之外）并且在您的 web 应用中使用它们。Web Components 也是一个浏览器原生支持的组件化方案，允许你创建新的自定义、可封装的HTML 标记，使用时不用加载任何额外的模块。自定义组件和小部件基于 Web Components 标准构建，可跨现代浏览器工作，并可与任何支持 HTML 的 JavaScript 库或框架一起使用。

其实简单理解 Web Components 就是：Web Components 是一套技术，允许创建可重用的自定义元素

而 Web Component 的目的也很明确，从原生层面实现组件化，使开发者开发、复用、扩展自定义组，实现自定义标签。意味着前端开发人员开发组件时可以实现 Write once, run anywhere。

Web Components 本身不是一个单独的规范，也不是一门单一的技术，而是由一组 DOM API 和 HTML 规范所组成。它其中就包含了：

ES Modules（ESM）相信大家非常熟悉了，作为组件的引入方式成为 Web Components 的规范之一。其实早期并不是使用的 ES Modules 作为 Web Components 的导入方式，而是 HTML Imports，可惜 HTML Imports 已经被废弃，如果想正常使用 HTML Imports 代码查看效果，可以安装低版本浏览器。

ES Modules（ESM）使 Web Components 能够以模块化方式开发，这与其他接受的 JavaScript 应用程序开发实现保持一致。您可以在 JS 文件中定义自定义元素的接口，然后将其包含在 type="module" 属性中。

HTML templates 利用 template 进行元素包裹，包裹的元素不会立即渲染，只有在内容有效的时候，才会解析渲染，具有这个属性后，我们可以在自定义标签中按需添加我们需要的模板，并在自定义标签渲染的时候再去解析我们的模板，这样做可以在 HTML 有频繁更改更新任务，或者重写标记的时候非常有用。

Custom elements 通过 CustomElementRegistry 来自定义可以直接渲染的 html 元素，并提供了组件的生命周期 connectedCallback、disconnectCallback、attributeChangedCallback 等提供给开发者聚合逻辑时使用。

Shadow Dom 被称为 影子DOM」 或 「隐式 DOM」，顾名思义，具有隐藏属性，具体的意思就是说，在使用 Shadow DOM 的时候，组件标签内的 CSS 和 HTML 会完全的隐式存在于元素内部，在具体页面中，标签内部的HTML 结构会存在于 #shdaow-root，而不会在真实的 dom 树中出现。其实这个 Shadow Dom并不陌生，在前端开发时使用的很多 HTML 标签中已经将它运用起来。例如常见的 video标签。

其实 Web Components 并不是近几年才出现的规范。

最早在 2011 年的时候 Google 就推出了 Web Components 的概念，也算是前端发展的早期了。那时候前端还处于百废待兴的一个状态，前端甚至都没有「组件化」的概念，但是就是这个时候 Google 就已经凭明锐的嗅觉察觉到「组件化」是未来发展的趋势，所以提出了 Web Components 。不过在最开始时 Google 也只是提出了这样一个概念，并没有去实现它，所以并没有出现太大的浪花。

2011 年 React 框架也诞生了。

到了 2013 年，Google 浏览器和 Opera 浏览器联合推出 Web Components 规范的 v0 版本。这也算是 Web Components 最早的版本了。

2013 年 React 框架开源。

2014 年 Vue 框架诞生，这里为什么要提到 Vue 框架了？因为 Vue 作者在创建 Vue 的时候大量参考了 Web Components 的语法。

在 2016 年 2 月， Shadow DOM 和 Custom Element 被并入 DOM 标准规范里面，而不再作为独立的规范存在。

在 2017 年 Google I/O 上，Polymer 框架发布2.0 版本，而这次升级的最主要意义就是将 Shadow Dom 和 Custom Elements 升级到 v1 版本，从而获得更多浏览器支持下一 代 Web Components 规范。

然后在 2018 年，Shadow DOM 和 Custom Element v2 在 Chrome、Safari、三星浏览器上已经支持，还被 Firefox 列为要支持的特性。

所以 Web Components 并不是一个新的概念，它已经存在很长时间了，只是可能还没有全面的进入研发者的视野。

尽管 Web Components 可能还没有全面的进入研发者的视野，现在还备受争议，但是它已经被很多大厂已经直接或者间接将它用于实践，比如：Twitter、YouTube、Electronic Arts、Adobe Spectrum、IBM 等等大厂（当然不止于此）。

在 Chrome 浏览器中对 customElements.define 至少调用一次的页面加载百分比统计也可看出 Web Components 已经相当流行。

data origin: chromestatus.com/metrics/fea…

再通过 Web Components 在 Chrome 浏览器的增长趋势也可以看出 Web Components 的增长十分亮眼。

data origin: chromestatus.com/metrics/fea…

并且在市场上也出现了很多 Web Components 库，可以轻松的使用和构建 Web Components，例如：

随着前端的发展，前端以 React、Vue、Angular 为主的框架也日益完善，大家肯定很奇怪，现在的前端框架不是挺好的吗？为什么我们还需要 Web Components 了? 最大的原因在于 Web Components 建立在 Web 标准之上。

虽然框架组件很棒，但它们只在自己的生态系统中很棒。您不能（轻松）在 React 中使用 Angular 组件，也不能（轻松）在 React 中使用 Vue 组件，反之亦然。而 Web Components 建立在 Web 标准之上，它们将可以在所有生态系统中工作，这也决定了它有巨大的优势：

除此之外，Web 组件还具有向下的交叉兼容性，这对于随着不断变化的 Web 环境向前发展至关重要。

虽然 Web Components 有着巨大的优势，但是也存在一些限制，如果你正在使用它，那请注意了。例如：

Web Components 优势明显，能彻底改变 Web 的开发，但是目前来说还需时日，需要做大量工作才能使 WebComponents 变得真正优秀，才能让大家享受到「组件化」 Web 开发的便利。但请大家不要混淆，Web Components 并不是为了取代任何现有框架而生，Web Component 的目的是为了从原生层面实现组件化，可以使开发者开发、复用、扩展自定义组件，实现自定义标签，解决 Web 组件的重用和共享问题，并使 Web 生态保持持续的开放和统一。