Re: [whatwg/dom] Atomic move operation for element reparenting & reordering (Issue #1255)

> And perhaps adoption of abstractions is so overwhelming that it's indeed compelling to introduce moveBeforeOrMaybeInsert() at some point, but not before we are much more confident about the problem space.

@annevk That's the core issue I suppose. If you are not confident of the problem space, then you just do not understand the problem. 

This api gained traction, interest and has been shared because it was supposed to solve "reconciling/moving trees of nodes make nodes lose state", not because "we will know if a node will lose state when moved". These are two different things, nobody expected the last one.

Every single framework/library implements tree reconciling, on which things lose state when these are moved/added/delete/ordered/filtered/re parented. That's the issue with priority to solve. 

Nobody wants this, and I do not understand how this works, we are giving feedback, and we are being shushed away and dismissed with completely unrelated arguments.

If you insist and want this, then look for a new name, such `moveBeforeHappyThrow`, because I didn't promote and share this API with my people for it to be hijacked into something that I do not want.

Btw, its shape doesn't make sense. We have the short and nice, ergonomic, forgiving and friendly `node.before(other)`, `node.after(other)` and this one is `parent.moveBefore(node, ref)` when it should have been `moveThis.moveBefore(thisOtherNode)` while also being forgiving and friendly.

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

Message ID: <whatwg/dom/issues/1255/2501766878@github.com>