Michael Bleigh
<template>
<core-ajax url="http://some.url" auto response="{{categories}}"></core-ajax>
<template repeat="{{category in categories}}">
<category-item category="{{category}}" on-click="{{openCategory}}"></category-item>
</template>
</template>
Scott Miles
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/c1b45f02-d3e6-4028-a905-998dbcce548c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Michael Bleigh
Rob Dodson
The problem here is that it would actually be quite useful to my application if all of those <category-item> elements lived in the Light DOM. I could bind events to individual categories or highlight one based on pushState URL changes, etc
To answer this question, it’s helpful to ask yourself, “Who owns this set of elements?”
Scenario 1: The category-list owns the category-items
If the category-item elements are owned entirely by the category-list element, then you probably want to add these event bindings inside of category-list. In this scenario, it’s really the model of category-list that is driving the creation, removal, and manipulation of the category-item elements. If you need to add a new category-item, you call a method on category-list, pass in some data, and the model stamps out the templates again.
ex:
var catList = document.querySelector(‘category-list’);
catList.add(dataItem); // this generates a new category-item by updating catList’s model
Because category-list owns all of the category-items, it handles the responsibility of highlighting a category-item based on pushState URL changes.
Scenario 2: An outsider owns the category-items
This sounds closer to what you’re thinking. You’d like category-items to be readily accessible for outside forces to act upon. This means the real owner of category-list/items is some parent element. If this is the case, then that outside element should be creating and manipulating new category-items, not the category-list itself. It will be the job of this parent element to watch for pushState changes and highlight the correct category-item.
So you can still use Polymer’s template bindings to manipulate your category-items, you just wouldn’t do it from *inside* category-list, you’ll have to do it from the outside. Which leads to the next question...
I feel like the natural end of a "do it in the Shadow DOM" philosophy is my page is just going to end up looking like this:
<body>
<my-app></my-app>
</body>
Yes, that would be the end result of trying to use Polymer’s features to bind all of the elements in your application together. While a <my-app> element might look a little weird—because it’s very different from how we typically build web apps—it’s not altogether a bad thing. When you view source you will only see <my-app> but if you open the dev tools you should be able to inspect the entire application. It might seem scary to put things in the Shadow DOM because you think they’re “hidden,” but perhaps a better way to think of Shadow DOM is not that things are hidden, but that they are “local.” So if you open <my-app> in the dev tools you’ll see the things that are local to my-app. That might be a few large pieces of your application. And if you open any one of those pieces, you’ll see the things that are local to it. That actually sounds quite reasonable to me.
Another way to think about it: If you’re writing a program in C++ or Java then you’ll always have a main() method that kicks things off. You can think of index.html as if it were this main method. When we write web apps today, we basically stick all of our markup in index.html, which is kind of like sticking all of your code in main(). <my-app> allows you to better compartmentalize this code, the same way objects allow you to better structure your Java or C++ programs.
In the example above, theoretically the "user" of my element could be rendering the page from the server and pre-populating the <category-item> tags without requiring an AJAX call.
A <my-app> element could probably work well for client-side rendering, but if you need server-side rendering then you’d probably want something that more closely resembles the current generation of web apps. If you want to add <cateogry-item> elements to a <category-list> using server-side technologies then you’d want to use a version of scenario 2 from above. Maybe employing a server side templating language. Here’s an example using EJS:
<category-list>
<% categories.forEach(function(category) { %>
<category-item category=<%= category %>></category-item>
<% }) %>
</category-list>
Because this data is coming from the server, there’s no need to generate it inside of the Shadow DOM of <category-list>. Just add the elements as if you were adding <li>’s to a <ul>.
given my category example before, wouldn't it be pretty cool to be able to simply append a new <category-item> element to the <category-list> and that automatically and transparently creates a new category?
You can do this, but you’ll want to choose either scenario 1 or scenario 2 from above. Trying to have it both ways (a list that is generated by a template, but also accepts nodes appended at runtime) is going to be tough.
I think this is a complex issue and may become a common point of confusion/frustration for developers as they start to really think about web components for application architecture. Light DOM and Shadow DOM, to me at least, seem to more or less cleanly map to public and private APIs. Things in the Light DOM can and should be touched, manipulated, added. Things in the Shadow DOM are implementation details.This encourages some actually quite interesting ideas around application structure. For instance, given my category example before, wouldn't it be pretty cool to be able to simply append a new <category-item> element to the <category-list> and that automatically and transparently creates a new category?If an element serves little purpose but to wrap and expose a collection of sub-elements which could each be addressed individually, forcing the user to reach into the Shadow DOM seems like a mistaken approach. I'd just like to start some discussion around this. A colleague of mine indicated that in the <polymer-element> definition you could just add a "lightdom" attribute to make <template> work on the Light DOM. That doesn't seem to be true in recent releases, was it ever?
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/c1b45f02-d3e6-4028-a905-998dbcce548c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/1f907118-5451-42da-86c7-317820196b0c%40googlegroups.com.
Michael Bleigh
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/c1b45f02-d3e6-4028-a905-998dbcce548c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arthur Evans
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/75462e3a-1893-421a-982c-748fe1c8ad4a%40googlegroups.com.