The spec says:

However, note that connectedCallback can be called more than once, so any initialization work that is truly one-time will need a guard to prevent it from running twice.

What does this mean? Is it saying that connectedCallback can be called more than one time (by the browser engine) before disconnectedCallback is ever called?

If there is always one connectedCallback for every disconnectedCallback, then that statement is rather pointless.

I will obviously clean up whatever I create in connectedCallback in disconnectedCallback, thus I will not have things "running twice".

The spec says:

However, note that connectedCallback can be called more than once, so any initialization work that is truly one-time will need a guard to prevent it from running twice.

What does this mean? Is it saying that connectedCallback can be called more than one time (by the browser engine) before disconnectedCallback is ever called?

If there is always one connectedCallback for every disconnectedCallback, then that statement is rather pointless.

I will obviously clean up whatever I create in connectedCallback in disconnectedCallback, thus I will not have things "running twice".

• javascript
• html
• web-ponent
• custom-element

Share Improve this question Follow edited Mar 5, 2019 at 22:25 trusktr asked Feb 25, 2019 at 20:32 trusktrtrusktr 45.7k5858 gold badges211211 silver badges287287 bronze badges 14

• You can detach a node from the dom, and reattach it. I don't think it can run twice without the disconnected handler running. And I don't think it's pointless: plenty of people don't really understand cleaning up after oneself, even if you do. – Jared Smith Commented Feb 25, 2019 at 20:36
• 1 Haha, well, I don't think those people would be the ones reading the spec anyways. – trusktr Commented Feb 25, 2019 at 20:39
• 1 Good point. Touche. – Jared Smith Commented Feb 25, 2019 at 20:40
• The spec doesn't guarantee that the disconnectedCallback will be executed before the connectedCallback. So if you rely on this asumption you may experiment son unwanted side effects. – Supersharp Commented Feb 26, 2019 at 22:29
• @Supersharp Do you mean the order of calls could be constructor --> connectedCallback --> connectedCallback --> disconnectedCallback, or similar? Does any browser ever do that in practice? If so, in which case? Doesn't seem like a good idea for any browser to do that. – trusktr Commented Feb 26, 2019 at 23:10

 |  Show 9 more ments

1 Answer 1

Sorted by: Reset to default 4

All depends on what you're doing in the callbacks, and how many attach/detach events you might reasonably expect. If it's really plex, and if your node might be moved around a lot in the DOM, then it's definitely worth considering events versus renders. In other words, event loop considerations. Take the following example:

var square = document.createElement('custom-square');
var one = document.getElementById('one');
var two = document.getElementById('two');
one.appendChild(square);
two.appendChild(square);
one.appendChild(square);
two.appendChild(square);

In this example you would get several connectedCallbacks and several disconnectedCallbacks: one for each appendChild. However all of these back-to-back appendChild calls are all happening in the same cycle of the event loop.

So while you get four separate connectedCallback calls and also three separate disconnectedCallback calls, the node is only rendered once, appended to #two.

This won't always be a concern, but since most modern browsers try to render at 60 FPS, that means you've got less than 17ms per render cycle to do all of your JavaScript, and for the browser to do all of its parsing/flowing/rendering for a given frame.

If it bees a concern, you could guard against these sorts of things by deferring appropriate work to a requestAnimationFrame callback, and then cancel that rAF if you have future connectedCallback events before the next render event, since you probably only care about the very last one.