Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ebidel opened this issue Nov 29, 2013 · 37 comments
Closed
Assignees

Comments

@ebidel
Copy link
Contributor

ebidel commented Nov 29, 2013

I'm updating the site the latest Thanksgiving Odyssey Bowertopia Feast and running into issues with inline 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.

@sjmiles
Copy link
Contributor

sjmiles commented Nov 29, 2013

The recommended way is:

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.

In Canary under native stuff,

"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.

@ebidel
Copy link
Contributor Author

ebidel commented Nov 29, 2013

HTML Imports flag is off and Experimental Web Platform features flag is on.

@sjmiles
Copy link
Contributor

sjmiles commented Nov 29, 2013

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
aware of this permutation.

In Canary, with "Experimental Platform Features" I can't find a problem.
I'll keep looking.

On Fri, Nov 29, 2013 at 1:29 PM, Eric Bidelman notifications@github.comwrote:

HTML Imports flag is off and Experimental Web Platform features flag is
on.


Reply to this email directly or view it on GitHubhttps://github.com//issues/357#issuecomment-29538328
.

@sjmiles
Copy link
Contributor

sjmiles commented Nov 29, 2013

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:

bower install Polymer/polymer-ui-elements#master

@sjmiles
Copy link
Contributor

sjmiles commented Nov 29, 2013

Here is a simpler version that uses menu and an inline Polymer element, to track more closely to what you posted:

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).

@ebidel
Copy link
Contributor Author

ebidel commented Nov 29, 2013

Ugh. Finally tracked this one down. The error occurs when the path to polymer.html is absolute:

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

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.

@ebidel
Copy link
Contributor Author

ebidel commented Nov 29, 2013

We also have subpages that may use something like:

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

@sjmiles
Copy link
Contributor

sjmiles commented Nov 29, 2013

The intent is that the absolute URLs match, so it should not matter how you
format the url.

On Fri, Nov 29, 2013 at 3:48 PM, Eric Bidelman notifications@github.comwrote:

We also have subpages that may use something like:


Reply to this email directly or view it on GitHubhttps://github.com//issues/357#issuecomment-29541770
.

@ebidel
Copy link
Contributor Author

ebidel commented Dec 2, 2013

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.

@dfreedm
Copy link
Member

dfreedm commented Dec 2, 2013

I suppose the simplest thing for vulcanize to do is treat a leading '/' as an absolute url and not attempt to inline it.
@ebidel Does this sound like a reasonable solution?

@ebidel
Copy link
Contributor Author

ebidel commented Dec 2, 2013

+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.

@sjmiles
Copy link
Contributor

sjmiles commented Dec 2, 2013

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

@ebidel
Copy link
Contributor Author

ebidel commented Dec 3, 2013

There are a couple of discoveries here:

  1. absolute URLs don't resolve correctly in the imports polyfill (https://github.com/Polymer/HTMLImports/issues/42)
  2. Vulcanize should leave "/" prefixed URLs as is. (https://github.com/Polymer/vulcanize/issues/6)
  3. My last example uses two URLs that resolve to different locations. (this bug)

For #3, Polymer clobbers a page with elements on it:

screen shot 2013-12-02 at 4 06 05 pm

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:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script src="http://code.jquery.com/jquery-1.10.2.min.js"></script>

@sjmiles
Copy link
Contributor

sjmiles commented Dec 3, 2013

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.

@ebidel
Copy link
Contributor Author

ebidel commented Dec 3, 2013

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 👎

@sorvell
Copy link
Contributor

sorvell commented Dec 3, 2013

An important part of our new bower strategy is that apps should be able to
rely on canonical paths for imports:

Ideally, we can use this everywhere.

On Mon, Dec 2, 2013 at 4:59 PM, Eric Bidelman notifications@github.comwrote:

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 importedhttps://github.com/Polymer/docs/blob/master/_includes/samples/tk-element.html#L1from 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 Polymer/vulcanize#6 https://github.com/Polymer/vulcanize/issues/6and 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 [image: 👎]


Reply to this email directly or view it on GitHubhttps://github.com//issues/357#issuecomment-29674317
.

@sjmiles
Copy link
Contributor

sjmiles commented Dec 3, 2013

What Steve said, although he meant:

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

A primary reason we chose the Bower dependency convention was so that all shared resources are considered available at ../.

@ebidel
Copy link
Contributor Author

ebidel commented Dec 3, 2013

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.

@sjmiles
Copy link
Contributor

sjmiles commented Dec 3, 2013

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.

@sjmiles
Copy link
Contributor

sjmiles commented Dec 3, 2013

WRT the practical problem, where does

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

come from?

If we can remove polymer-all from that URL, then the immediate problem is resolved, if I understand correctly.

@ebidel
Copy link
Contributor Author

ebidel commented Dec 3, 2013

On Mon, Dec 2, 2013 at 8:01 PM, Scott J. Miles notifications@github.comwrote:

The only complete salve for this problem on the table is the one we are
presenting.

Another is to fix it from the Polymer side :)

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.

I'm game to push Bower as the recommended way to work with Polymer,
elements, and web components. I've found it very convenient so far for my
existing projects.

Put Bower aside for a second. It gives us a convention but not following
that convention shouldn't break apps. There should be no consequences of
loading Polymer from two different URLs. Every library supports this use
case: http://jsbin.com/UhAqOFaf/1/edit

People can still "reference CDNs, roll their own stuff", we are not trying

to limit that as much as you might think.

But this fails:

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 in a canonical path.

After that, individual projects can modulate the imports themselves for
whatever custom set up they have.

The downside is that I have to modulate at all! The less munging users have
to do, the better.

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.

Using a package manager, build tools (Vulcanize bugs withstanding), and
Bower for flat deps is something we're doing on the site. I'm a bit biased,
but it's a shining real-world example of using everything together.

But back to munging....if I've hit issues so quickly, so will others. My
question still stands, is there a technical reason not to do this?


Reply to this email directly or view it on GitHubhttps://github.com//issues/357#issuecomment-29681977
.

@sjmiles
Copy link
Contributor

sjmiles commented Dec 3, 2013

Another is to fix it from the Polymer side :)

Ok, so we fix Polymer. This is only one of thousands of potential cases of this problem.

it gives us a convention but not following that convention shouldn't break apps.

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.

Every library supports this use case: http://jsbin.com/UhAqOFaf/1/edit

(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.
(2) in the world we are aiming for, there are thousands (if not hundreds of thousands) of shareable things, not a few dozen top libraries. In this world, putting the onus on the items themselves to de-dupe does not scale.

But this fails:

<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.

The downside is that I have to modulate at all!

Same answers as above. There is no magic sauce.

the site ... is a shining real-world example of using everything together.

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.

But back to munging....if I've hit issues so quickly, so will others. My question still stands, is there a technical reason not to do this?

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.

@ebidel
Copy link
Contributor Author

ebidel commented Dec 4, 2013

Missed your previous reply. Keeping "polymer-all/" is mainly for not
breaking people and preserving existing URLs. App Engine doesn't allow you
to create redirects without implementing a server :\

On Tue, Dec 3, 2013 at 11:02 AM, Scott J. Miles notifications@github.comwrote:

Another is to fix it from the Polymer side :)

Ok, so we fix Polymer. This is only one of thousands of potential cases
of this problem.

We can't fix everyone but we can worry about our own stuff!

it gives us a convention but not following that convention shouldn't
break apps.

I 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.

Every library supports this use case: http://jsbin.com/UhAqOFaf/1/edit

(1) each of those includes is loading the file off the network and
executing the code, much of this is simple redundancy (cost). No exceptions
is not evidence of awesomeness.
(2) in the world we are aiming for, there are thousands (if not hundreds
of thousands) of shareable things, not a few dozen top libraries. In this
world, putting the onus on the items themselves to de-dupe does not scale.

FTR, I'm not advocating items should de-dupe themselves but I am advocating
we de-dupe ourselves. IMO we're a bit of a different beast. Our element,
, is a service for developers. It allows them to create
other custom elements. If runs into the re-register problem,
no big deal; it doesn't load. If attempts a re-register,
none of your page elements work.

The problem exacerbates when you move to the world of 1000s of shareable
things. Requiring people to have exactly one URL to use Polymer is pretty
limiting. I bower install a new element that uses a CDN version of
polymer...now I'm off on a goose chase rewriting URLs. Or, download all the
contents of
because it's not on Bower.

But this fails:

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.

I broke *the convention, *not the rules.

The downside is that I have to modulate at all!

Same answers as above. There is no magic sauce.

the site ... is a shining real-world example of using everything together.

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.

But back to munging....if I've hit issues so quickly, so will others. My
question still stands, is there a technical reason not to do this?

Conventions only work by adoption. So, yes others will hit this, it will
require education.

I can make things work, but I'm advocating for others here: the maximum
flexibility to use our stuff. In some ways, it feels like we're going down
the Bower highway with no off-ramps and I want to gut check that. Are we ok
with saying, "You can't use Polymer (or any elements that use it) unless
everything is installed local to your app"? Honest question.

The technical reason is again as above: extreme sharing requires a holistic

solution to the duplication problem.


Reply to this email directly or view it on GitHubhttps://github.com//issues/357#issuecomment-29740149
.

@sjmiles
Copy link
Contributor

sjmiles commented Dec 4, 2013

You can't use Polymer (or any elements that use it) unless everything is installed local to your app"? Honest question.

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:

Keeping "polymer-all/" is mainly for not breaking people and preserving existing URLs

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.

@ebidel
Copy link
Contributor Author

ebidel commented Dec 7, 2013

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. (<link rel="import" href="polymer.html"> vs. `/polymer-all/components/polymer/polymer.html). I've had to comment out the dependency in each example to get things working again: https://github.com/Polymer/docs/blob/master/samples/components/tk-element-proto.html#L1

@ebidel
Copy link
Contributor Author

ebidel commented Dec 7, 2013

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:

www.ppo.org/articles/page.html:
    <link rel="import" href="/elements/vulcanized.html">
    <link rel="import" href="demos/communication/elements.html">

www.ppo.org/elements/vulcanized.html:
    <script src="../components/polymer/polymer.js"></script>

www.ppo.org/articles/demos/communication/elements.html:
    <link rel="import" href="../../../components/polymer/polymer.html"> <!-- import polymer dep -->
    <polymer-element>
      ...
    </polymer-element>

(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 <script src="polymer.js"> and subsequent imports of polymer.html won't know to be de-duped. If that's case, we need to find a solution that works with our recommend tool :)

ebidel added a commit to Polymer/old-docs-site that referenced this issue Dec 8, 2013
@dfreedm
Copy link
Member

dfreedm commented Dec 9, 2013

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?

@sjmiles
Copy link
Contributor

sjmiles commented Dec 9, 2013

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.

@dfreedm
Copy link
Member

dfreedm commented Dec 9, 2013

Actually, the markup suggestion I made is lame. It would probably require putting that attribute on all the instances of polymer.html.

Instead we can have a config file that lists excludes:

{
  "exclude": [
    "polymer.html"
  ]
}

And a --config option to the binary

vulcanize --config config.json index.html

@AlessandroEmm
Copy link

Any News on this? Or an alternative solution for the people who cannot use bower, because they integrate partials served by different hosts? 👍

@fabriziomoscon
Copy link

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 polymer along with angular.js.
After removing <base href="/"> and loading the components absolutely like so <script src="/components/platform/platform.js"></script> a specific page went into an infinite spinning allocating up to 2Gb of RAM and chrome killing the tab.

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

@sjmiles
Copy link
Contributor

sjmiles commented Jul 11, 2014

If there are good reasons not to load components absolutely

@fabriziomoscon: Relative vs absolute paths don't matter, if that's what you mean. Also, you have referenced platform.js, which has no dependencies and so will not generally cause this problem.

an alternative solution for the people who cannot use bower,

@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:

  1. not throwing an error if you load polymer.html twice: this is wont-fix
  2. being able to properly de-duplicate components from separate sources: this is a problem for HTMLImports at the spec level. We are working on it, but it's a slow process because it's not something we can just fix in Polymer.
  3. being able to vulcanize into non-overlapping segments. This problem is made harder by missing features in HTMLImports, so we are working on this too at the spec level. However, there are also possible improvements we can make in Vulcanizer, this work is underway.

@AlessandroEmm
Copy link

@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.
Thank you guys!

@sjmiles
Copy link
Contributor

sjmiles commented Jul 11, 2014

@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.

load is a run-time concept. Since Bower has nothing to do with run-time, it therefore cannot be a solution to any loading problem. As I said, this continues to be a point of confusion.

It's possible folks are saying Bower when they mean installing components to my server instead of using another server. This has nothing to do with Bower, and instead has to do with the de-duplication support as described in my message.

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.

Can Polymer be loaded as an AMD/CommonJS Module? That would certainly solve my problem.

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.

@AlessandroEmm
Copy link

@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.

@sjmiles
Copy link
Contributor

sjmiles commented Jul 11, 2014

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.

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.

Many people have expressed this concern. It's not a solved problem.

@tjsavage
Copy link
Contributor

Closing this issue due to age and the release of version 1 of Polymer - please feel free to re-open if this is incorrect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants