第三方聚合物元素答案

【问题标题】：Third Party Polymer Elements第三方聚合物元素
【发布时间】：2014-03-29 22:11:31
【问题描述】：

我试图了解聚合物是否是为特定用例构建的——第三方 Web 组件。

我需要完成的是创建一个 Web 组件，该组件将来自调用者页面的图像 url（元素上的属性可以）作为输入，并在聚合物组件内部使用 HTML5 画布以特殊方式呈现图像。

在我看来，聚合物目前似乎不是为第三方使用而制造的。原因：

必须对调用者的页面有足够的控制权才能将platform.js 添加到<head>，特别是<head>
我的platform.js 版本可能与调用者页面的platform.js 不同（或者说我用聚合物的JS obj 污染了页面，对吧？）
在非chrome浏览器样式和其他标签被注入<head>，可能与源页面冲突
如果想要设置选项以避免 FOUC，则必须控制调用者的 <body> 标签

传统上，我所有的 Web 组件都是通过 iframe 构建的，我希望将我的方法现代化，以期实现“shadow-dom 未来”。

有没有办法以第三方安全的方式使用聚合物？也许与 [lightningjs?

【问题讨论】：

Fwiw，如果您最终确实需要并且（可以负担）iframe 可以提供的那种装甲，我（未经测试）的印象是，是的，lightningjs.com 可能是一条路。跨度>
platform.js 需要放在头脑中吗？因此，最好为外部站点创建“插入”组件，例如 facebook 的登录组件。我想你可以提供可以加载聚合物的 js 并在之后嵌入聚合物标签元素的 sn-ps。我想这比为消费者粘贴 IFrame 代码更糟糕了。

标签： javascript iframe polymer shadow-dom

【解决方案1】：

Polymer 和 Web 组件完全围绕第 3 方使用而构建，这是一个核心设计支柱。

IMO 最广泛的概念是，开发人员将能够访问网络并找到众多可供选择的 Web 组件。这与能够从大量 JQuery 插件中进行选择没有什么不同，但具有更大程度的互操作性和组合，因为每个实例都可以被视为传统元素。

平台.js

Platform.js 正在对称为 Web 组件的未来浏览器功能进行建模。现在进行这项工作有实际的现实，所以是的，为了让第三方完全使用 Web 组件，他们需要选择加入 platform.js（以及所有这些）包含）。确实，这一事实使得（今天）在未经某人同意的情况下将 Web 组件注入到某人的页面中是很困难的。

我的 platform.js 版本可能与调用者页面的不同

如上所述，platform.js 是使用 Web 组件的前提条件。这就是为什么它被命名的原因。除非主页所有者包含此功能，否则他不会提供您可以提供 Web 组件的平台。

这与现代图书馆没有什么不同，例如查询。如果您不小心，您可以在一个文档中加载多个 JQuery 副本和/或版本，但这很浪费。协调是首选。

除了platform.js，Web Components 围绕 N 个模块使用 M 个依赖项，并且所有模块都以最佳方式协同工作。这是共享是设计支柱的另一种方式。

在非chrome浏览器中，样式和其他标签被注入，可能与源页面冲突

这就是 polyfilling 的全部代价。如果你需要环境的纯净，你将不得不等到 Web Components 被广泛地原生实现。实际上，样式标签非常专业，不太可能与任何东西发生冲突。

如果想要设置选项以避免 FOUC，则必须控制调用者的标签

这并不完全正确，您可以构建 Web 组件，在一定程度上控制自己的 FOUC。但这需要很多额外的工作，而且作为第三方，你真的无法知道某些开发人员将采用什么样的加载机制或惯用语，因此在没有他的合作的情况下试图编排太多会很困难。

传统上，我所有的 Web 组件都是通过 iframe 构建的

IFRAME 与 Web 组件有很大不同。 IFRAME 是一个全新的上下文，因此您拥有更多的安全网，但它是重量级的，并且存在协调成本。

虽然platform.js 本质上正在改变共享平台，但自定义元素本身不需要与用户的全局命名空间或他的 CSS 混淆（尽管他们可以）。代码可以限制在元素的原型中，CSS 和 DOM 可以隐藏在 ShadowDOM 中。总体意图是，除非有人想要，否则这些都不需要从元素中泄漏出来。

【讨论】：