On Fri, Nov 6, 2015 at 5:12 PM, Domenic Denicola <d...@domenic.me> 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
