Re: [whatwg/dom] Proposal: New method to reorder child nodes (#891)

I came across this issue while searching for existing solutions for part of a UI library I'm writing. In essence, the DOM needs a way to move a child node among its sibling nodes without going through the state reset issues caused by having to first take the node out. 

This is possible for special cases where we can just move well-behaved sibling nodes `.before()` and `.after()` nodes that are trickier to deal with, like `document.activeElement`, iframes, custom elements with `connectedCallback()`, &c. For the general case, we start needing to find out how to minimize the nodes that we move - which means we have to find the longest common subsequence between the current and desired `childNodes`. That translates to massive diff, patch, and state normalizing algorithms - all just to try to minimize the number of times we need to (attempt to correctly) reset reordered element state.

Fundamentally, we could solve this by adding in a primitive operation that moves a node without removing it from its parent first. It wouldn't actually "break" anything except for in a hypothetical pathological case with a third party `MutationObserver` making bad assumptions, since this operation is equivalent to moving sibling nodes instead. For convenience, we can have analogs for `before`, `prepend`, `append`, `after`, `replaceChildren`, and `replaceWith` that simply don't start by removing their own child nodes.

Just consider how much more efficient it would be to add a `.replaceChildren()` analog that only had to internally switch its `childNodes`. Reconciliation (both very time and space-complex) would be massively simplified, **leading to browsers decreasing resource consumption by massive amounts** for certain classes of UI's. UI libraries get to shrink and browsers have to deal with less code across the board. It would be an absolute shame to block this on the grounds of *maybe* breaking a backwards third party's `MutationObserver`.

I'm sure that we will have to also make something along the lines of `MutationRecord.movedNodes` too. In any case, this issue is *much* more important than it seems to be getting attention for.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/891#issuecomment-913964493