I guess because 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> 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. If something like this is the case (maybe AJAX, maybe server-injected) then other parts of the app may be looking for/depend on events from those <category-item> elements. To me the Light DOM is a kind of Public API, so it makes sense to populate it with semantic, useful elements that your consumers can use. Does that make sense? On Thu, Mar 13, 2014 at 10:43 PM, Scott Miles <[email protected]> wrote: > It would be helpful if you could explain in more detail why you want your > example elements to exist in light DOM. > > >> I could bind events to individual categories or highlight one based on > pushState URL changes, etc. I might even be able to alter attributes of the > individual category and save them back. > > I believe this is all dramatically easier to do in Shadow DOM, so hence my > confusion. > > FWIW, we like to suggest that the light DOM is the province of the user of > your element. Your element emitting or modifying it's own light DOM is > mostly an anti-pattern. > > > On Thu, Mar 13, 2014 at 10:04 PM, Michael Bleigh <[email protected]>wrote: > >> To me, the promise of Polymer is to use the DOM as representative an >> engine of application state. To that end, one area that I'm a bit unclear >> about is what to do when I want to use template and mdv semantics to create >> things in the Light DOM. Let me give an example... >> >> Let's say I have a sidebar like in Google Groups that is listing >> categories. I would probably construct an element like <category-list> and >> perhaps also a <category-item> that would be able to use AJAX to fetch the >> list of categories and then display them. This is easy enough with Shadow >> DOM: >> >> <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> >> >> So far so good. 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. I might even be able to alter >> attributes of the individual category and save them back. >> >> Hiding all of the children in the Shadow seems like a less-than-ideal >> situation, but I don't know of another way to do it without manually >> instantiating each node and using appendChild (and therefore losing all >> benefits of MDV and data binding). >> >> Is there a convention for this? What should the right pattern be here? >> >> 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 [email protected]. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/c1b45f02-d3e6-4028-a905-998dbcce548c%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/c1b45f02-d3e6-4028-a905-998dbcce548c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CABrD70CVXMrSkcfVYmi%2BF_x0wOV2kpNg8RWXu6_ZAcNU7XyPdg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
