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/CAEKsHmCXNMvs36opCV%3D-ZvaWOCNRKDzPci3jXYs8GZH1q3ic0A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
