polymer: Element (re)registration errors when loading polymer.html more than once

I’m updating the site the latest Thanksgiving Odyssey Bowertopia Feast and running into issues with inline <polymer-element>s. The recommended way is:

<head>
    <script src="components/platform/platform.js"></script>
    <link rel="import" href="components/polymer/polymer.html">
    <link rel="import" href="components/polymer-ui-menu/polymer-ui-menu.html">
</head>
<body>
  <x-hi></x-hi>
  <polymer-element name="x-hi">
    ...
  </polymer-element>
</body>

In Canary under native stuff, mixing element imports and explicitly loading polymer.html in the main page causes re-registration errors:

screen shot 2013-11-29 at 12 42 50 pm

The quick fix is for me to move the element into an import, but we should make these two scenarios play well together.

About this issue

  • Original URL
  • State: closed
  • Created 11 years ago
  • Comments: 37 (33 by maintainers)

Commits related to this issue

Most upvoted comments

I think we need to be mindful that many developers won’t be using Bower, or use it in tangent with their own solutions. Everything works great if you stay strictly in Bower’s world, but we’ll have people that reference CDNs, roll their own stuff, and mix and match. We should make this stuff play well together. I’ve already shown how easy things break down if you go off the vision. My use cases are pretty common.

Is there a technical reason not to prevent the aforementioned badness? If no, we should help users out.

FWIW, loading polymer.html more than once from a different URL causes the same error. Example:

<link rel="import" href="/components/polymer/polymer.html">
<link rel="import" href="../polymer-all/components/polymer/polymer.html">

I discovered this updating the demos on polymer-project.org. The error kills pages that load inline samples. Each sample imports polymer.html as a dep, but from a different URL than the base template. I’d update the URLs to match each other, but Vulcanizer rewrites filesystem paths, not URLs. It strips out the first import in my example.

ATM this is a blocker for updating the site.

I’ve been in the de-dupe camp too, but after experiencing the pain trying to update the site, we need re-entry protection. Many people will inadvertently hit this hurdle and I don’t want them to go through the same frustration.

Imagine a world where users are importing elements that reference polymer.html from different CDNs.

element-one.html:

<link rel="import" href="http://cdn1.com/polymer.html">

element-two.html:

<link rel="import" href="http://cdn2.com/polymer.html">

Hosed!

A similar example is a site that imports it’s own version of polymer.html and elements that import it from another location. This is most akin to to what polymer-project.org does. People can take out the site import, but they shouldn’t have to. Nor should they have to worry about the details of where things are coming from.


Details on what I’m doing:

We have a complex dance of using Vulcanize, dogfooding Polymer, and show/running samples that use it.

Our elements are setup to load polymer from a relative URL:

<link rel="import" href="../polymer/polymer.html">

Resolves to http://www.polymer-project.org/polymer-all/components/polymer/polymer.html

The samples are imported from another location:

<link rel="import" href="/components/polymer/polymer.html"> 

Resolves to http://www.polymer-project.org/components/polymer/polymer.html

The different location is a URL rewrite and is necessary to show a cleaner URL, closer to the one readers will use with Bower.

Fixing https://github.com/Polymer/vulcanize/issues/6 and resolving URLs correctly in the HTML Imports polyfill will fix 90% of this mess, but I’m worried about other developers here. It’s way too easy to kill your page 👎