@brandondees I think this is from the import/clone phase of the element birth. We override <link rel=import>.onimport event on each instance of the custom element so the last element is the one that actually triggers the event. This is the nature of on events as they traditionally can only have one event handler attached to them. Great for defaults as in our on* event conventions. But horrible when you want to trigger n events. Will revert to using an addEventListener strategy as this is how to handle multiple events from the same <link rel=import> makes total sense as there will only be ONE <link rel=import> for n clones.
@brandondees I think this is from the import/clone phase of the element birth. We override
<link rel=import>.onimport
event on each instance of the custom element so the last element is the one that actually triggers the event. This is the nature ofon
events as they traditionally can only have one event handler attached to them. Great for defaults as in ouron*
event conventions. But horrible when you want to triggern
events. Will revert to using anaddEventListener
strategy as this is how to handle multiple events from the same<link rel=import>
makes total sense as there will only be ONE<link rel=import>
forn
clones.EventTarget.connectedCallback
(triggered each instance) Where 🐛 bug is. Only the last.onimport
gets handled. as previous get overriden -> https://github.com/devpunks/snuggsi/blob/master/elements/event-target.es#L27-L31Element.onimport
routine -> https://github.com/devpunks/snuggsi/blob/master/elements/component.es#L42-L62Why/when to use
EventTarget.addEventListener
-> https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#NotesHTMLLinkElement.onimport
event -> https://github.com/devpunks/snuggsi/blob/master/elements/html-link-element.es#L15-L37 Hopefully we won't have to upstream this to webcomponents.js polyfill. We rely heavily on their "When imports ready" event.