Re: [webcomponents]: Moving custom element callbacks to prototype/instance

On Wed, Mar 6, 2013 at 4:26 PM, Blake Kaplan <> wrote:
> On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov <> wrote:
>> 1) Somehow magically chain "create" callbacks. In Lucy's case,
>> <foo-lucy> will call both Raj's and Lucy's callbacks.
>> 2) Get rid of a separate lifecycle object and just put the callbacks
>> on the prototype object, similar to printCallback
>> (
>> I am leaning toward the second solution, but wanted to get your opinions.
> I also like the second solution, but Hajime's point about the
> mutability and general exposure of the lifecycle methods is a good
> one. Is there a motivation for having the lifecycle objects on the
> prototype as opposed to being passed in as an "ancestor" parameter?
> XBL1, as I understand it, automatically calls the
> constructor/destructor of "extended" bindings, but given the ad hoc
> nature of web components' inheritance, it seems like it would be much
> less surprising to make this stuff explicit *somewhere* (i.e. in the
> actual components rather than in the engine).

I think the idea of placing callbacks on the prototype was the
simplest to do, given that prototype inheritance provides all the
right machinery. If we deem this being a terrible idea, we'll need to
fallback to something like passing ancestor. But then we'll be going
against the grain of JS.


Received on Friday, 8 March 2013 17:52:07 UTC