Hi, I’ve managed to understand how to use Polymer with Meteor after a long struggle. I thought I would cross-post this from an answer I gave up in another meteor thread, since I can imagine some people are really curious about this.
You can see it in action working here (though I have no idea about bugs + I haven’t actually checked if the polyfill is broken right now … sometimes somehow I manage to make it break in FF/IE/Safari)
You can see it here ( the markers are data from a mongo collection and you can filter them. Disable “silk screen” under “processes” to see it work). This is done with shady DOM, not the old shadow DOM polyfill.
Meteor and Polymer don’t work that well together out of the box. Why? When you use a custom-element such as
<paper-dropdown></paper-dropdown>
Polymer generates DOM like this
<paper-dropdown>
<div>
<div>this is a random visualization to visualize div soup</div>
</div>
</paper-dropdown>
Now, if you have something like this:
<paper-dropdown>
{{#each bla}}
<paper-item>blubb</paper-item>
{{/each}}
</paper-dropdown>
Meteor get’s all confused because of the DIV soup and it’s like "What, I don’t get it, where am I supposed to put the paper-items in the #each helper? With shadow DOM this does not happen, because custom-elements with native shadow DOM are essentially normal HTML elements that you have built yourself. The old shadow DOM polyfill therefore works with Meteor - but is freaking slow.
As of today, only Chrome and Opera support shadow DOM. Safari has recently implemented shadow DOM but it is not yet shipped. Edge and Firefox are most likely working on the integration right now as well (just about 1-2 months ago all browser vendors agreed on a final v1 of shadow DOM).
Since the shadow DOM polyfill is slow, Google/smart people at https://github.com/webcomponents/webcomponentsjs came up with shady DOM, which roughly emulates shadow DOM, but not as strict as the old polyfill. It works a lot faster but: DIV soup that makes meteor and other frameworks sad.
Now, how do we solve this? Simple! We don’t generate new HTML elements with meteor. Instead, we only pass data (objects, arrays) to a custom Polymer element. This custom element contains all the frontend stuff we need. So in case of a {{#each}} helper what we do is this:
<map-view map-data='{{map-data-meteor'}}></map-view>
map-data is a property defined in the custom element “map-view”, whereas map-data-meteor is data that is pushed to the element via a meteor helper. Now in our template, we are able to just generate the elements similarly to how the each would work:
<template is='dom-repeat' items='{{mapData}}'>
<paper-item>{{item.somedata}}</paper-item>
</template>
Bam, magic! This is the gist of it. I’m really, really trying to reach out to people to help meteor get a better integration with Polymer. Either by creating custom DOM insertion that uses Polymer’s DOM api or by creating a router that handles stuff better. Ideally, we would get rid of blaze and jquery because we don’t need them. All we need is a way to include our custom-element and pass data to it, that’s it.
