-
Notifications
You must be signed in to change notification settings - Fork 489
removeChild followed by appendChild results in no detached/attached callbacks #311
Comments
I think this is by design? due to the async nature of MutationObserver, it's impossible to deliver attached/detached the same way spec'd CE will. So by the time we'd deliver the detached/attached, the callback wouldn't reflect current state of the doc, e.g. we'd say "detached" when it's in the document or "attached" when it's not. That seems bad too. Hence the guard: https://github.com/webcomponents/webcomponentsjs/blob/master/src/CustomElements/observe.js#L55 Not sure how we can do better given constraints of existing browsers. Maybe we could special case deatched->attached and make it do something different from attached->detached. Or maybe a polyfill only callback to mean "node moved" ... |
Hmmm, it's ironic, because in my code snippit above, what I really wanted to do was just I say ironic, because in the case that you just I guess the choice is, given the fact that we can't match the exact behavior on polyfill, in the case that you remove-then-append in a turn, is it better to eat all the callbacks (current), or give a detached with wrong position? Given that's exactly what you get when you don't do the (otherwise unnecessary) remove before appending, the latter seems slightly better given the loss of notification. That said, I realize there are other cases like append-then-remove, and in that case not being able to rely on the parent et.al. being correct seems bad. Will discuss with @sorvell on other ideas... |
ah, good point
yeah, that makes sense. +1 from me, fwiw :) |
Ensure attached & detached occur for moves in the same turn. Fixes #311
fix LGTM 👍 |
Is this a duplicate of #18? |
Repro in test case here: https://github.com/Polymer/polymer/pull/1591/files#r30874592
Removing
takeRecords
in following code results in no callbacks being called:The text was updated successfully, but these errors were encountered: