On Thu, Feb 6, 2014 at 8:37 PM, Sébastien Cevey <[email protected]>wrote:
> On 6 February 2014 05:59, Dominic Cooney <[email protected]> wrote: > > I was about to post to this ML to ask a very similar question, so pardon > me for hijacking this thread: > > >> Shadow DOM isn't a lock-box, there's also projection with <content>. It >> might be an interesting exercise to say "what should my markup look like?" >> and then try to work from there. >> > > I've just encountered a similar dilemma to Justin while building a > monitoring dashboard using Polymer. > > Please let me know if any of what I'm trying to do is an anti-pattern or > if there is a better alternative. > > The idea is to reuse custom elements through composition and a shared > interface: > > I've got a <my-chart> custom element that renders the data found in the > <table> it contains as a visual chart: > > <my-chart render="bar"> > <table>...</table> > </my-chart> > Yeah, it's interesting, isn't it? When there are elements like tables we kind of get into a grey area. I think your touchstone should be: How do I want people to be able to use my element? If I want people to be able to whack a my-chart around a table and render it, then yes, you should make that work. There's nothing that says this is the ONLY way my-chart can source its data, though... > Now I'd like to be able to feed data to <my-chart> from various sources, > as per the <polymer-ajax> example Dominic mentioned, through composition: > > <my-chart render="bar"> > <aws-cloudwatch metric="latency"></aws-cloudwatch> > </my-chart> > > <my-chart render="bar"> > <other-monitoring present="throughput"></other-monitoring> > </my-chart> > > > The problem here is that by default, the <aws-cloudwatch> and > <other-monitoring> elements will load data and populate a <table> _in their > Shadow DOM_. > > There seem to be two obvious solutions (not sure how technically doable > they are, I haven't tried yet): > > 1. Make <my-chart> look at the Shadow DOM of its children, rather than > their DOM. > 2. Make <aws-cloudwatch> and <other-monitoring> somehow populate their > DOM, rather than their Shadow DOM. > > Answering the "what should my markup look like?", it feels like 2. is most > reasonable (we want the tabular data in the DOM for clients to see, > right?). Is it right, or feasible? It doesn't feel like <content> would > help, though I might be mistaken. > > Alternatively, is this a misuse of Web Components? > > > I'd love to hear what you guys think and what are the suggested patterns > to do this, as it feels like composition of Web Components could be hugely > valuable! > I would definitely be using databinding and not DOM for this kind of composition. Assume you're in the middle of my-app, something like: <polymer-element name="my-app" attributes="data"> ... .. nonvisual stuff, push data into the model .. <aws-cloudwatch metric="latency" sink="{{data.latency}}"></aws-cloudwatch> .. visual stuff, pull data out of the model .. <my-chart render="bar" source="{{data.latency}}"></my-chart> It should not feel icky to have aws-cloudwatch not be a child of my-chart. That relationship might be convenient at first, but what if you want to have a chart AND a label that has 90 %-ile latency? Then you're going to want to have two visual widgets slurping off the same data and having the data source be a child of one element but not the other would be weird. It's also fine to have a complex data model in a given element. What's not OK is if some irrelevant detail of the my-app's data model bleeds into aws-cloudwatch or my-chart. It's neat if my-chart can also read from tables, and you could make it do that if source is missing or whatever. But I wouldn't make that the primary way to push data into it. If you end up slurping data from tables a lot, you might like to make a component which does that--wraps a table and brings its data into the databound world. > Thanks, > > -- > Sébastien Cevey > Software Developer > > Please consider the environment before printing this email. > ------------------------------------------------------------------ > Visit theguardian.com > > On your mobile, download the Guardian iPhone app theguardian.com/iphone and > our iPad edition theguardian.com/iPad > Save up to 57% by subscribing to the Guardian and Observer - choose the > papers you want and get full digital access. > Visit subscribe.theguardian.com > > This e-mail and all attachments are confidential and may also > be privileged. If you are not the named recipient, please notify > the sender and delete the e-mail and all attachments immediately. > Do not disclose the contents to another person. You may not use > the information for any purpose, or store, or copy, it in any way. > > Guardian News & Media Limited is not liable for any computer > viruses or other material transmitted with or as part of this > e-mail. You should employ virus checking software. > > Guardian News & Media Limited > > A member of Guardian Media Group plc > Registered Office > PO Box 68164 > Kings Place > 90 York Way > London > N1P 2AP > > Registered in England Number 908396 > > -------------------------------------------------------------------------- > > > -- Email SLA <http://goto.google.com/dc-email-sla> • Google+<https://plus.sandbox.google.com/111762620242974506845/posts> 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/CAHnmYQ_aCN%2B1xkD%3D7d5gLbRSXGMuh4%2BS5-pSE6-q4zuNd-Vw4Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
