RE: Callback when an event handler has been added to a custom element
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
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
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
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
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
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
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 <mailto: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 <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
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 mailto: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 <mailto:mmi...@gmail.com>] Sent: Thursday, November 5, 2015 4:05 PM To: public-webapps mailto: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
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
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
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