As I mentioned, our philosophy at the moment is that the code itself should be as close as possible to optimized for run-time use. Additionally, we prefer that the bower-able packages have as little non-runtime content as possible. Both principles are aimed to reduce our general footprint.
However, this is all on a spectrum. Current exceptions to the code rule include meta-data in comments, which today we use for documentation and cataloging. We could conceivably expand this metadata to accommodate tooling, it's all a matter of balance. Designer (nee Sandbox) uses separate metadata files to do it's thing. Our experience is that IDE tools can take advantage of more metadata than we are comfortable putting directly into the run-time file. Current exceptions to the package rule include legal claptrap (which we want to reduce; at this level of granularity, reproducing each of those files N times is poor ergonomics), the demo file, and the index.html file (all of which I'm still stressing about =P). Scott On Fri, Feb 21, 2014 at 6:12 PM, Justin Fagnani <[email protected]>wrote: > Joining this thread a little late, but I'd like to come back to the > original topic of declaring the public interface for a custom element. > We've talking about this in person, but to recap: > > I think this is critical for good tooling for custom elements. Tools can't > assume this fixed set of elements where they know all the events, > properties and attributes of an element. This is obviously an issue for > design-time tools, but runtime tools have problems too: a framework that > wants to support way data binding needs to be able to understand the > relationship of attributes, properties and events, so that it can properly > use them to bind to a single "property". > > I'm not sure how the sandbox demo figures out what properties to make > editable in the inspector, does it use the attributes attribute? If so, > does it then use Node.bind with that attribute name, or does it just set > the attribute? > > -Justin > > > > On Fri, Feb 14, 2014 at 11:41 PM, Scott Miles <[email protected]> wrote: > >> The reason we haven't done this is because it would be unique in our >> system to have live DOM or JavaScript code whose only purpose is >> documentation. I'm not saying it's off the table, but it would be crossing >> a line. All other declarations (in particular `attributes`) have a runtime >> function, any documentary service is incidental. >> >> >> On Fri, Feb 14, 2014 at 8:40 PM, Sergey Shevchenko >> <[email protected]>wrote: >> >>> ...and as commented by Seth Ladd on the said Dart Web Development: >>> >>> <quote> >>> >>> I'd love this. >>> >>> I see four APIs for custom elements: >>> >>> * Custom attributes >>> * Custom events >>> * Children elements (yes, even adding a child element is a type of API) >>> * The elements imperative API (aka pure Dart code) >>> >>> I hope we can demonstrate superior toolability for all surface areas of >>> a custom element. >>> >>> </quote> >>> >>> On Friday, February 14, 2014 8:38:10 PM UTC-8, Sergey Shevchenko wrote: >>> >>>> Hi all, >>>> >>>> (reposting from Dart Web Development) >>>> >>>> With "attributes", we have some way to succinctly communicate to an >>>> element's users what properties they can set at the instantiation point. >>>> Why don't we have something similar for custom events that an element can >>>> fire? Something like: >>>> >>>> <polymer-element name="my-element" attributes="height width" >>>> custom-events="open activate"> >>>> >>>> ... >>>> >>>> <my-element height="100" width="200" on-open="onOpen" >>>> on-activate="onActivate"></my-element> >>>> >>>> The way it is now, users are left to either rely on the documentation >>>> (unreliable) or hunt all fire() and asyncFire() calls in the element's >>>> code. >>>> >>>> If "custom-events" were added, it would be nice to also check, for >>>> every fire()/asyncFire() call, that the element actually declares the event >>>> being fired. >>>> >>>> I bet all this would save a lot of debugging hours for a lot of people. >>>> >>>> --Sergey >>>> >>> 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/a6394d86-c4c1-4070-80e1-cca9840c776d%40googlegroups.com >>> . >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> 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/CAHbmOLZrFs%3DA24hGyP9Ab8uHDeMqsSUU1%2BQB%3Dd7dpUzSC8TEKg%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > 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/CAHbmOLZ-cHY7WSARR1yyr1iX_xb0z7JRaVYfSiGPoZnZmUOcdw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
