2

I want to know how to modify Polymer 1.0 tags after creation via jQuery or virtual DOM.

I am trying Polymer 1.0 with Mithril.js. Polymer 0.5.5 has Shadow DOM and its tag literal and internal structure (on Chrome's inspector) are almost same. But 1.0 uses shady DOM and it works as HTML template.

Source:

<paper-element>hello world</paper-element>

Polymer 0.5.5 result on inspector:

<paper-button role="button" tabindex="0">hello world</paper-button>

Polymer 1.0 result on inspector:

<paper-button role="button" tabindex="0" aria-disabled="false" class="x-scope paper-button-0">
  <paper-ripple class="style-scope paper-button">
     <div id="background" class="style-scope paper-ripple"></div>
     <div id="waves" class="style-scope paper-ripple"></div>
  </paper-ripple>
  <paper-material animated="" class="content  style-scope paper-button x-scope paper-material-0" elevation="0">
    hello world
  </paper-material>
</paper-button>

For example, performing jQuery command like this:

$("paper-element").text("new label");

It works with 0.5.5 (it shows correct label), but breaks 1.0 (internal tags have gone ant becomes just label). This new behavior is not good for manipulating Polymer's custom tags via other DOM manipulation library (at first, I hit this issue when I am playing Mithril.js). And I can't find any API to reinitialize internal tags.

Is there any good solution to modify Polymer 1.0 tag after creation to support virtual DOM or jQuery?

Update (6/3/2015)

I found solution from Polymer document. Polymer 1.0 can work on Mithril virtual DOM after adding the following snippet:

<script>
    window.Polymer = window.Polymer || {};
    window.Polymer.dom = 'shadow';
</script>

Polymer starts using Shadow DOM instead of default Shady DOM by this setting. It is as same as Polymer 0.5.5 and JavaScript DOM API friendly. Thank you guys!

Yoshiki Shibukawa
  • 4,739
  • 1
  • 13
  • 8
  • 1
    Setting Polymer's dom to 'shadow' does not solve the redraw problems you will get when shadow elements are updated and changed to DOM elements. Shadow DOM and Mithril don't work well together, and I guess this counts for all Virtual DOM libraries. – Arthur Clemens Jun 28 '15 at 01:28

2 Answers2

1

Ideally the paper-button would expose a property or method for modifying the contents, however the documentation does not list anything like this.

Fortunately it is still HTML, and can be worked with. On the demo page I selected one of the buttons in the Chrome Inspector and ran the below code to update the button's contents:

$0.querySelector('paper-material').innerHTML = 'testing';

In the Chrome console $0 refers to the element currently selected in the Chrome Elements Inspector, in this case one of the paper-button elements.

Zikes
  • 5,888
  • 1
  • 30
  • 44
  • Yes, your solution works fine. But it says we have to implement special component for each paper elements :( I tried "paper-drawer-panel" too, and it has completely different structure. – Yoshiki Shibukawa Jun 02 '15 at 00:27
  • 1
    It sounds like a great opportunity to upgrade the paper elements themselves! There's definitely a need for it, as you've seen, and it will require per-component knowledge at the moment, so I think an API consistently applied across the components set would be great. If I were you, I would submit it as a new issue at https://github.com/PolymerElements/paper-elements/issues – Zikes Jun 02 '15 at 02:09
1

Web components like those in the Polymer collection are difficult to customise and populate dynamically. The nature of shadow DOM makes it impervious to external influence, which is in my opinion a critical limitation of web components.

However, it is possible to reconstruct these elements as Mithril components to allow custom control. There is an excellent collection of material design elements made with Mithril on NPM and Github under the name Polythene.

Barney
  • 16,181
  • 5
  • 62
  • 76
  • 1
    I think it's disingenuous to say that web components are impervious to external influence, as my answer to this question clearly demonstrates a working solution which penetrates the shadow DOM. I think you could more accurately say that the nature of web components requires working knowledge of the component's internals, however, or that the component must provide a good API for internal access. I would call that a feature, however. – Zikes Jun 02 '15 at 14:20