A custom element registers a window resize listener and starts a fetch in connectedCallback. What goes wrong as the element is moved around the DOM, and how do you make the lifecycle safe?

## Why connectedCallback runs more than once The DOM has no move operation. `newParent.appendChild(el)` is defined as removing `el` from wherever it is and inserting it in the new place, and every custom element reaction follows that definition: `disconnectedCallback`, then `connectedCallback`, on the very same instance with the same fields intact. That happens when a list is reordered, when a component moves an element into a portal or a dialog container, when a framework re-parents a node during reconciliation, or when a developer temporarily detaches a subtree to batch mutations. So `connectedCallback` is best read as "you are live again", not "you were born". ## The two failure modes **Duplicate registration.** `window.addEventListener('resize', this.onResize)` in `connectedCallback` adds a second identical registration on the second connect. Because both use the same bound function reference, one `removeEventListener` will not undo two `addEventListener` calls, and the handler now runs twice per resize. After five moves, five times. **Leaks.** The element may be removed for good, but `window` still holds a reference to a handler that closes over the element. Nothing about detaching a node breaks that chain, so the element, its shadow tree and everything it references stay reachable. The element is gone from the page and alive in memory. The same applies to `setInterval`, to any observer you called `observe()` on, and to a subscription on a shared store. **Wasted or racing work.** A `fetch` started in `connectedCallback` keeps running after disconnect. On a move you get two in flight, and their responses can land in either order, so the element renders whichever finished last rather than whichever was requested last. ## The symmetric pattern The cleanest formulation is one `AbortController` per connection, because a single signal covers listeners, observers wired to abort, and requests: ```js class MyPanel extends HTMLElement { #ac = null; connectedCallback() { this.#ac = new AbortController(); const { signal } = this.#ac; window.addEventListener('resize', this.#onResize, { signal }); fetch('/api/panel', { signal }) .then((r) => r.json()) .then((data) => this.#render(data)) .catch((err) => { if (err.name !== 'AbortError') throw err; }); } disconnectedCallback() { this.#ac?.abort(); this.#ac = null; } } ``` On disconnect everything registered under that signal is released in one call, and on the next connect a fresh controller starts a clean generation. The `AbortError` filter matters: aborting a fetch rejects its promise, and an unfiltered rejection becomes an unhandled rejection in your logs on every move. Where a controller does not apply, do the symmetric thing manually: `clearInterval` what you set, `disconnect()` what you observed, unsubscribe what you subscribed. ## Disconnect is not destruction Two consequences people miss. First, a disconnect may be temporary. Do not throw away expensive derived state that you will need again half a millisecond later when the move completes; release *external* resources and keep internal state. If you need to distinguish a real removal from a move, check `this.isConnected` in a microtask or on the next task before doing expensive teardown — a move will have already reconnected by then. Second, `disconnectedCallback` is **not** called when the page unloads, when the tab is closed, or when the document is discarded. There is no guaranteed final callback for a custom element. Anything that must happen before the user leaves — flushing analytics, saving a draft — belongs on the page lifecycle events the platform provides for that purpose, not on element teardown. ## Making setup idempotent Alongside teardown, guard anything in `connectedCallback` that must happen only once or that would overwrite the author's markup: ```js connectedCallback() { if (!this.hasAttribute('role')) this.setAttribute('role', 'region'); if (!this.#rendered) { this.#renderOnce(); this.#rendered = true; } } ``` The combination — idempotent setup plus symmetric teardown — is what makes a custom element survive arbitrary re-parenting by code it has never heard of. That is the real bar, because a component author does not control how consumers move nodes around.