Re: Callback when an event handler has been added to a custom element

[Mitar]

Hi!

On Fri, Nov 6, 2015 at 5:12 PM, Domenic Denicola  wrote:
> In general I would be cautious about this kind of API. Events are not 
> expected to have side effects, and adding listeners should not cause an 
> (observable) action.

Hm, but message port API itself has such a side-effect:

http://www.w3.org/TR/webmessaging/#examples

"The key difference is that when using addEventListener(), the start()
method must also be invoked. When using onmessage, the call to start()
is implied."

So we already have an example of an interface where "start()" is
called automatically.

So how can I do something like that on the custom element as well?

> A better design in your case would probably be to have a specific method on 
> the custom element which "starts" it (and thus starts its associated message 
> port).

For me this feels like leaking internal implementation details to the outside.


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

RE: Callback when an event handler has been added to a custom element

[Domenic Denicola]

From: Mitar [mailto:mmi...@gmail.com] 

> Hm, but message port API itself has such a side-effect:

I think that is just a very bad API. The platform is unfortunately full of bad 
APIs :). In particular, a difference between two different ways of adding event 
listeners is not something authors ever think about.

But regardless, if that's all you want, you could do it easily by declaring 
your custom element class like so:

class MyCustomElement {
  set onmessage(handler) {
this.addEventListener("message", handler);
this.start();
  }
  // ...
}

> For me this feels like leaking internal implementation details to the outside.

I strongly disagree. I would instead say it feels like getting rid of magical 
implicit I/O behavior, in favor of making the code say what it does and do what 
it says.

RE: Callback when an event handler has been added to a custom element

[Domenic Denicola]

In general I would be cautious about this kind of API. Events are not expected 
to have side effects, and adding listeners should not cause an (observable) 
action. See e.g. https://dom.spec.whatwg.org/#action-versus-occurance which 
tries to explain this in some detail. A better design in your case would 
probably be to have a specific method on the custom element which "starts" it 
(and thus starts its associated message port). 

As such I don't think we should add such a capability to the custom element API 
(or elsewhere in the platform). Although it is possible to use such callbacks 
for "good" (using them only to perform unobservable optimizations, like lazy 
initialization), it is way too easy to use them for "evil" (causing observable 
effects that would better be allocated to dedicated action-causing methods).

Re: Callback when an event handler has been added to a custom element

[Elliott Sprehn]

On Fri, Nov 6, 2015 at 5:12 PM, Domenic Denicola  wrote:

> In general I would be cautious about this kind of API. Events are not
> expected to have side effects, and adding listeners should not cause an
> (observable) action. See e.g.
> https://dom.spec.whatwg.org/#action-versus-occurance which tries to
> explain this in some detail. A better design in your case would probably be
> to have a specific method on the custom element which "starts" it (and thus
> starts its associated message port).
>
> As such I don't think we should add such a capability to the custom
> element API (or elsewhere in the platform). Although it is possible to use
> such callbacks for "good" (using them only to perform unobservable
> optimizations, like lazy initialization), it is way too easy to use them
> for "evil" (causing observable effects that would better be allocated to
> dedicated action-causing methods).
>
>
I agree, this doesn't seem like something authors should do. You element
should use the attachedCallback to "start" doing something, and the
detachedCallback to stop. You can also have an explicit start() API so
callers could make it begin before it's been inserted into the page. Events
are passive notification of the operation of the element.

- E

Re: Callback when an event handler has been added to a custom element

[Justin Fagnani]

You can also override addEventListener/removeEventListener on your element.
My concern with that, and possibly an event listener change callback, is
that it only works reliably for non-bubbling events.

On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> Interesting. Alternatively, you can add .onwhatever handlers, as well as
> define your own overload of addEventListener (which will be called instead
> of the EventTarget.addEventListener method). That way you can capture all
> attempts at setting events on your element.
>
> -Original Message-
> From: Mitar [mailto:mmi...@gmail.com]
> Sent: Thursday, November 5, 2015 4:05 PM
> To: public-webapps 
> Subject: Callback when an event handler has been added to a custom element
>
> Hi!
>
> We are using message ports to communicate with our logic and are wrapping
> the API into a custom element. The issue is that we would like to call
> start on a message port only after user has registered an event handler on
> the custom element instance. But it seems there is no way to get a callback
> when an event handler is added.
>
> So I am suggesting that there should be a callback every time an event
> listener is added to a custom element (and possibly one when removed).
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
>

Re: Callback when an event handler has been added to a custom element

[Olli Pettay]

On 11/06/2015 09:28 PM, Justin Fagnani wrote:

You can also override addEventListener/removeEventListener on your element. My 
concern with that, and possibly an event listener change callback, is
that it only works reliably for non-bubbling events.

How even with those? One could just add capturing event listener higher up in 
the tree.
You need to override addEventListener on EventTarget, and also relevant onfoo 
EventHandler setters on Window and Document and *Element prototypes,
but unfortunately even that doesn't catch onfoo content attributes (). But one could use MutationObserver then to
observe changes to DOM.


-Olli




On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead > wrote:

Interesting. Alternatively, you can add .onwhatever handlers, as well as 
define your own overload of addEventListener (which will be called
instead of the EventTarget.addEventListener method). That way you can 
capture all attempts at setting events on your element.

-Original Message-
From: Mitar [mailto:mmi...@gmail.com ]
Sent: Thursday, November 5, 2015 4:05 PM
To: public-webapps >
Subject: Callback when an event handler has been added to a custom element

Hi!

We are using message ports to communicate with our logic and are wrapping 
the API into a custom element. The issue is that we would like to call
start on a message port only after user has registered an event handler on 
the custom element instance. But it seems there is no way to get a
callback when an event handler is added.

So I am suggesting that there should be a callback every time an event 
listener is added to a custom element (and possibly one when removed).


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Re: Callback when an event handler has been added to a custom element

[Justin Fagnani]

On Fri, Nov 6, 2015 at 12:44 PM, Olli Pettay  wrote:

> On 11/06/2015 09:28 PM, Justin Fagnani wrote:
>
>> You can also override addEventListener/removeEventListener on your
>> element. My concern with that, and possibly an event listener change
>> callback, is
>> that it only works reliably for non-bubbling events.
>>
> How even with those? One could just add capturing event listener higher up
> in the tree.
>

Good point. I forgot that capturing works with non-bubbling events :(


> You need to override addEventListener on EventTarget, and also relevant
> onfoo EventHandler setters on Window and Document and *Element prototypes,
> but unfortunately even that doesn't catch onfoo content attributes ( onclick="doSomething">). But one could use MutationObserver then to
> observe changes to DOM.
>
>
> -Olli
>
>
>
>> On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead <
>> travis.leith...@microsoft.com >
>> wrote:
>>
>> Interesting. Alternatively, you can add .onwhatever handlers, as well
>> as define your own overload of addEventListener (which will be called
>> instead of the EventTarget.addEventListener method). That way you can
>> capture all attempts at setting events on your element.
>>
>> -Original Message-
>> From: Mitar [mailto:mmi...@gmail.com ]
>> Sent: Thursday, November 5, 2015 4:05 PM
>> To: public-webapps  public-webapps@w3.org>>
>> Subject: Callback when an event handler has been added to a custom
>> element
>>
>> Hi!
>>
>> We are using message ports to communicate with our logic and are
>> wrapping the API into a custom element. The issue is that we would like to
>> call
>> start on a message port only after user has registered an event
>> handler on the custom element instance. But it seems there is no way to get
>> a
>> callback when an event handler is added.
>>
>> So I am suggesting that there should be a callback every time an
>> event listener is added to a custom element (and possibly one when removed).
>>
>>
>> Mitar
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
>>
>>
>

Re: Callback when an event handler has been added to a custom element

[Boris Zbarsky]

On 11/6/15 3:44 PM, Olli Pettay wrote:

You need to override addEventListener on EventTarget, and also relevant
onfoo EventHandler setters on Window and Document and *Element prototypes


Are we trying to just do this best-effort, or reliably?  Because this:

 var ifr = document.createElement("iframe");
 document.body.appendChild(ifr);
 ifr.contentWindow.EventTarget.prototype.addEventListener.call(myNode, 
whatever);


is obviously hard to handle without serious effort...

-Boris

Re: Callback when an event handler has been added to a custom element

[Jonas Sicking]

On Fri, Nov 6, 2015 at 12:44 PM, Olli Pettay  wrote:
> On 11/06/2015 09:28 PM, Justin Fagnani wrote:
>>
>> You can also override addEventListener/removeEventListener on your
>> element. My concern with that, and possibly an event listener change
>> callback, is
>> that it only works reliably for non-bubbling events.
>
> How even with those? One could just add capturing event listener higher up
> in the tree.
> You need to override addEventListener on EventTarget, and also relevant
> onfoo EventHandler setters on Window and Document and *Element prototypes,
> but unfortunately even that doesn't catch onfoo content attributes ( onclick="doSomething">). But one could use MutationObserver then to
> observe changes to DOM.

This problem also applies to the original proposal in this thread.

Even if we add the ability to detect when an eventlistener is added to
a custom element, what happens if an eventlistener is added to an
ancestor node? Or if the custom element is moved into a new element
which already has an ancestor with such an event listener.

/ Jonas

RE: Callback when an event handler has been added to a custom element

[Travis Leithead]

Interesting. Alternatively, you can add .onwhatever handlers, as well as define 
your own overload of addEventListener (which will be called instead of the 
EventTarget.addEventListener method). That way you can capture all attempts at 
setting events on your element.

-Original Message-
From: Mitar [mailto:mmi...@gmail.com] 
Sent: Thursday, November 5, 2015 4:05 PM
To: public-webapps 
Subject: Callback when an event handler has been added to a custom element

Hi!

We are using message ports to communicate with our logic and are wrapping the 
API into a custom element. The issue is that we would like to call start on a 
message port only after user has registered an event handler on the custom 
element instance. But it seems there is no way to get a callback when an event 
handler is added.

So I am suggesting that there should be a callback every time an event listener 
is added to a custom element (and possibly one when removed).


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m