在最近的一次 An Event Apart 演讲中,Dave 指出,Web Components 现在才真正成为生产环境 Web 开发的实用选择。例如,Edge 采用 Chromium 才一年左右。在此之前,Edge 不支持任何 Web Component 内容。如果您很久以前就发布了它们,那么您就必须使用相当大的 polyfill,或者采用渐进增强的方式,如果它们失败,则会以优雅的方式或在受控的环境中失败,例如每个人都使用相同计算机的内联网(或者是在类似 Electron 的东西中)。
在我看来,Web Components 还有很长的路要走才能让大多数开发者感到吸引,但它们正在逐步实现。我认为推动其采用的一件事是,得益于 ES 模块以及 import
JavaScript 的便捷性,预构建组件的开发者体验(DX)变得无比简单。
我之前就提到了这一点:看看 Nolan Lawson 的表情符号选择器有多么简单
只需要一行 JavaScript 和一行 HTML 代码就能使其运行,再加一行 JavaScript 代码就能将其连接起来并返回一个选择结果的 JSON 响应。
确实令人信服。可以说,这就是所谓的 DX。
像这样的 Web Components 并非孤例,因此本文的标题就是如此。Dave 整理了一个 很棒的独立组件 列表。也就是说,不是更大更复杂系统1的一部分的 Web Components,而仅仅是本身就有用的一个小巧组件,就像表情符号选择器一样。Dave 的代码库列出了大约 20 个这样的组件。
以 GitHub(这家公司)的这个组件为例,一个复制到剪贴板的 Web Component
对于一个大小约为 3KB 的组件来说,这很不错。它的生产方式随您的意愿而定。您可以从 CDN 上使用它。也可以将其捆绑到您的代码中。或者将其保留为按需的单次使用。无论哪种方式,它都非常易于使用。就这个独立组件而言,甚至都没有 Shadow DOM 需要处理。
这并不是在贬低 Shadow DOM,它可能是 Web Components 最实用的功能(并且无法由库复制,因为它是一个原生浏览器功能),但是对其进行样式设置的选项 并不是我最喜欢的。如果您使用了三个不同的独立组件,它们对如何通过 Shadow DOM 进行样式设置有三个不同的观点,这将会变得很烦人。
我设想,开发者会先试用这些东西,看到其好处,然后在构建的内容中越来越多地使用它们,甚至创建自己的组件。从 Web Components 构建设计系统在我看来是一个真正的甜蜜点,就像许多知名品牌2已经做到的那样。
我们的梦想是让人们真正整合常见的 UI 模式。就像,即使我们永远无法得到原生的 HTML “标签”,也可能有一个 Web Component 可以提供它们,并使 UI、UX 和可访问性完美无缺,同时保持其可样式化,以便任何网站都可以使用它们。但首先,它需要存在。
如果你在 15 年前发布了这些示例,使用
<div>
而不是import
以及带有特定类的<div>
,没有人会感到惊讶。自从我第一次听说它们以来,我就不明白 web 组件有什么大不了的。当然,您可以只使用
<div class=clipboard></div>
。但 web 组件的价值可能与<video>
标签相当:默认显示(按钮等)以及交互(播放、暂停、拖动等)都被封装到一个 HTML API 中。要使用
<video>
,只需阅读 该标签的文档。哦,看,一个完整的<video>
JS API!playbackRate
!字幕 API!) 太棒了!您可以通过HTML
和CSS
完成基本操作,或者通过JS
进行更高级的操作。因此,只需将这种思维方式移植到任何东西。web 组件是一种非常棒的设计,可以将各种功能封装到 web 开发人员都熟悉的形式中。我不理解,所以我不喜欢。咆哮!
当然,但您可以将该代码片段放到任何地方吗?您可以确保代码和样式不会与任何其他内容冲突吗?它可以与框架无关吗?或者,正如您提到的 15 年前,它的 jQuery 会与我的 jQuery 冲突吗?
我不想吹毛求疵,但剪贴板复制示例在我的 Edge(v90,Win 10)上不起作用。不过它在 Chrome 中立即生效了。
很可能是 teething problems,但还是!
可能是 iframe 造成的。
尝试调试模式。 https://cdpn.io/chriscoyier/debug/ZELdMvB
出于某种原因,它在 CodePen 上不起作用。以下是一个可行的示例: https://github.github.io/clipboard-copy-element/examples/
我真的很高兴看到 Web Components 越来越接近“生产就绪”状态。自从几年前 Shadow DOM 在 Firefox 中登陆以来,我一直关注着它们。
我认为,与网页相比,它们为需要使用 JS 的 web 应用提供了很好的机会,如果您不介意这种不太现实的非黑即白的框架。
在后者中,web 组件的激增会给渐进增强带来额外的复杂性,或者——我担心——意味着更少的用户可以访问内容——无论出于何种原因,安全、隐私等。
当然,标准的 HTML 元素可以放置在自定义元素中,并使用 CSS 进行样式设置以进行回退。毫无疑问,这是可能的。
对于表情符号选择器来说,这不是问题,因为它只是锦上添花,但当我听到我的同事建议重建卡片甚至“具有额外功能的链接”时,我有点担心。有时会这样。
是的,那个 LWC “手风琴” 都是老式的代码。
您可以使用标准的 HTML <detail> 和 <summary> 来创建一个手风琴,并由一个 Web Component 单行代码 管理
已记录: https://dev.to/dannyengelman/acme-the-accordion-web-component-in-187-bytes-47ah
我不认为那个手风琴示例是 Web Component。在我看来,真正的 Web Components 不会泄漏实现细节,例如类名,也不需要特定的 HTML 结构才能实际工作。一个真正的手风琴 Web Component 应该是这样的
基本上,Web Component 应该是一个自包含的概念,具有通过属性进行的声明式行为定义,以及通过其
class extends HTMLElement
类定义进行的命令式 API。(并且有可能需要其他 Web Components 作为子级,以便进行复杂的交互,就像<ul>
需要<li>
一样。)