Element (re)registration errors when loading polymer.html more than once #357
Comments
There is no reason to load polymer.html in your example, so this is not the recommended way. Most of the time you should not have to concern yourself with polymer.html as it's part of a dependency sequence. The only time you actually need to depend on polymer.html in your index.html is in the specific case where you have inline polymer elements in the main document and no imports that depend on polymer.
"Under native stuff" is not specific enough. Are you using native imports? We expect imports to de-duplicate, so polymer.html should be protected from re-entry at a low level. If you are using native imports, it could be a bug in de-duplication. If you are not using native imports, then it's a bug in the polyfills. |
|
HTML Imports flag is off and Experimental Web Platform features flag is on. |
|
I can't reproduce this problem. I checked my versions (it's still possible I've messed up, of course). Afaict, native imports are a non-starter because the polyfill is not yet In Canary, with "Experimental Platform Features" I can't find a problem. On Fri, Nov 29, 2013 at 1:29 PM, Eric Bidelman notifications@github.comwrote:
|
|
I made this project on a remote server: http://turbogadgetry.com/titled/ it successfully does <link rel="import" href="components/polymer/polymer.html">
<link rel="import" href="components/polymer-ui-elements/elements.html">I created the dependencies with this command:
|
|
Here is a simpler version that uses http://turbogadgetry.com/titled-menu/ Imports look like this: <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">
<link rel="import" href="components/polymer-ui-menu-item/polymer-ui-menu-item.html">Working on my Canary (Windows 33.0.1723.0). |
|
Ugh. Finally tracked this one down. The error occurs when the path to which I suspect looks like a different URL to the registry? Too bad our examples weren't leading with a "/". This was frustrating to track down. |
|
We also have subpages that may use something like: |
|
The intent is that the absolute URLs match, so it should not matter how you On Fri, Nov 29, 2013 at 3:48 PM, Eric Bidelman notifications@github.comwrote:
|
|
FWIW, loading 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 suppose the simplest thing for vulcanize to do is treat a leading '/' as an absolute url and not attempt to inline it. |
|
+1 on that change for Vulcanize. But this needs to be fixed at the polymer level as well. Users should never get the dupe register error, no matter how many locations/times it's loaded. |
|
It's part of the HTML Imports specification that de-duplication happen for identical resolved URLs. The polyfill must do this properly, or it's a bug. It's not clear to me if what you have here are simply URLs that the polyfill is not resolving correctly, or two imports that actually refer to different resolved URLs |
|
There are a couple of discoveries here:
For #3, Polymer clobbers a page with elements on it: Can we check if polymer-element is already registered and noop? As data point, JQuery doesn't do anything unexpected if you load it from 2 different URLs: |
|
There are architectural issues here, it's important not to act tactically. So, before revisiting the basic nature of import de-duplication I want to understand why your application is trying to load polymer from two completely different locations. As of today, this is an application error. |
|
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: element-two.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: Resolves to http://www.polymer-project.org/polymer-all/components/polymer/polymer.html The samples are imported from another location: 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 👎 |
|
An important part of our new bower strategy is that apps should be able to Ideally, we can use this everywhere. On Mon, Dec 2, 2013 at 4:59 PM, Eric Bidelman notifications@github.comwrote:
|
|
What Steve said, although he meant:
A primary reason we chose the Bower dependency convention was so that all shared resources are considered available at |
|
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. |
|
The only real solution being offered for this problem right now is the one we are presenting. I think there is probably confusion about "stay in Bower's world". What we are proposing is not as limiting as it sounds. It's really just a convention, an escape hatch for the exact badness you are suffering. People can still "reference CDNs, roll their own stuff", we are not trying to limit that as much as you might think. In order to produce something that you can share and make readily available for other people to use in arbitrary contexts, you have to make some concessions to generality. Via imports, we can make this an easy concession: you refer to shared resources as imports on a canonical path. After that, individual projects can modulate the imports themselves for whatever custom set up they have. Additionally, if you are using a package manager, enabling flat dependencies is enough to have your package manager play nice in this world. Bower uses a flat dependency model by default. |
|
WRT the practical problem, where does
come from? If we can remove |
|
On Mon, Dec 2, 2013 at 8:01 PM, Scott J. Miles notifications@github.comwrote:
Put Bower aside for a second. It gives us a convention but not following People can still "reference CDNs, roll their own stuff", we are not trying
The downside is that I have to modulate at all! The less munging users have
But back to munging....if I've hit issues so quickly, so will others. My
|
Ok, so we fix Polymer. This is only one of thousands of potential cases of this problem.
I'm suggesting the opposite. The point of the convention is to avoid breaking apps, so not using the convention will break apps. And again, this has nothing to do with Bower, per se.
(1) each of those includes is loading a file off the network and executing the code, much of this is simple redundancy (cost). No exceptions is not evidence of awesomeness.
<head>
<link rel="import" href="http://cdn.com/polymer.html">Right, you broke the rules and it won't work properly that way. I can't make this problem go away for free, that's the point of the convention. My suggestion is that once one realizes the cost/benefit ratio, it's not that hard to accept.
Same answers as above. There is no magic sauce.
No argument! The question is how hard is this really to fix using the conventions. Maybe it only takes two minutes. I wish I could say more directly, but it's a complex setup, and I haven't reverse engineered it yet.
Conventions only work by adoption. So, yes others will hit this, it will require education. The technical reason is again as above: extreme sharing requires a holistic solution to the duplication problem. |
|
Missed your previous reply. Keeping "polymer-all/" is mainly for not On Tue, Dec 3, 2013 at 11:02 AM, Scott J. Miles notifications@github.comwrote:
The problem exacerbates when you move to the world of 1000s of shareable
The technical reason is again as above: extreme sharing requires a holistic
|
We are not saying that. I thing we need to have a sit-down to discuss this general topic. However, wrt fixing the site problem:
There is no reason to remove 'polymer-all' from existing or resolving. The question is why does the site itself refer to the same stuff via two different URLs. Modifying the URLs on the site that refer to 'polymer-all' can fix the problem. |
|
The different URLs are for simplifying the examples. To keep the examples simple, the elements in the Getting Started are shown + loaded from a different URL than the polymer-elements used on the site. ( |
|
To circumvent this issue, I've been rewriting the site to use a single import URL, but still running into re-register issues. For example, one page contains: (so the location of polymer resolves to the same location in this example) Note taking out the polymer.html in elements.html clears things up, but that should not be required since it's a dependency. This may boil down to Vulcanize? It produces |
|
A partial solution may be to add some hinting into vulcanize that will leave certain html imports alone. <link rel="import" href="polymer.html" no-vulcanize>WDYT? |
|
This is a significant issue, for my $0.02 I think we are going to need to have some brainstorming about how to go forward. Right now, I think vulcanize will probably need to take some kind of config file to spell out various behaviors for any particular build. |
|
Actually, the markup suggestion I made is lame. It would probably require putting that attribute on all the instances of Instead we can have a config file that lists excludes: {
"exclude": [
"polymer.html"
]
}And a
|
|
Any News on this? Or an alternative solution for the people who cannot use bower, because they integrate partials served by different hosts? 👍 |
|
Guys I appreciate you are carrying out a brainstorming to find the best solution for this issue. Meanwhile I was also affected. I spent 3 hours debugging this today. I am using If there are good reasons not to load components absolutely, please specify that more clearly in the docs, as it is very frustrating for early user of polymer and can definitely be a deal breaker. Thank you |
@fabriziomoscon: Relative vs absolute paths don't matter, if that's what you mean. Also, you have referenced
@AlessandroEmm: Not being able to use Bower also doesn't matter. Bower is just a way to access files and has nothing to do with run-time. I'm afraid this issue has lost it's context. There are a few actual issues here that probably need proper tickets:
|
|
@sjmiles While you're obviously right with bower not being needed at runtime, it has been the proposed solution to the polymer.html multiple load thing. Which is something that you can't do when you serve from components from multiple sources which is what I have been arguing about. Can Polymer be loaded as an AMD/CommonJS Module? That would certainly solve my problem. |
It's possible folks are saying Please refer to my message, and recognize that we are not choosing to disallow loading from multiple end-points: this is something that is forced on us by the behavior of HTMLImports today.
The thing is that we are not willing to allow loading multiple copies of Polymer. It's inefficient and problematic, and at best would obscure real problems with respect to de-duplication and versioning. This is why I indicated this as a wont-fix above. |
|
@sjmiles Thanks for putting it nicely, I totally agree with your message on the bower. I know about HTML Imports limitation. I have only been wondering about polymer.js not being able to load multiple times. While I agree that it's inefficient at runtime it may be needed to allow for flexible versioning in an environment where you just can't have all the development teams in sync versionwise. Anyway, I get that this is not a problem to anyone but me. Thanks. |
This is a problem for lots of people, you are not alone. I don't mean to suggest we don't consider this important, only that it's a thorny issue and we are trying to be very deliberate in how we approach it.
Many people have expressed this concern. It's not a solved problem. |
|
Closing this issue due to age and the release of version 1 of Polymer - please feel free to re-open if this is incorrect. |
I'm updating the site the latest Thanksgiving Odyssey Bowertopia Feast and running into issues with inline s. The recommended way is:
In Canary under native stuff, mixing element imports and explicitly loading polymer.html in the main page causes re-registration errors:
The quick fix is for me to move the element into an import, but we should make these two scenarios play well together.
The text was updated successfully, but these errors were encountered: