FYI a quick search shows that React has already integrated this on its main branch!<p><a href="https://github.com/facebook/react/pull/32036">https://github.com/facebook/react/pull/32036</a><p>I'm not exactly sure what the developer experience of this would be, but I expect it would make Portals significantly more powerful and able to be hot-swapped into different containers without disrupting either their internal state or even things like loaded iFrames. I expect others will be experimenting heavily with this now that there's platform support.<p><a href="https://github.com/facebook/react/issues/12247">https://github.com/facebook/react/issues/12247</a> (2018-2020) describes some of the use cases, with one partial solution being <a href="https://github.com/httptoolkit/react-reverse-portal">https://github.com/httptoolkit/react-reverse-portal</a> - the conversation around caveats of these approaches would be entirely different now!
htmx has supported moveBefore() since 2.0.3 in October of last year:<p><a href="https://github.com/bigskysoftware/htmx/blob/master/CHANGELOG.md#203---2024-10-03">https://github.com/bigskysoftware/htmx/blob/master/CHANGELOG...</a><p><a href="https://htmx.org/examples/move-before/" rel="nofollow">https://htmx.org/examples/move-before/</a><p>We initially asked for this new feature about two years ago and have worked with the Chrome team as they have implemented it. It is going to be a huge step forward for the web!
The biggest benefit to this is that it makes one of the slowest parts of virtual DOM diffing (longest common subsequence) no longer required. After this becomes supported in the mainstream, not even signal-based frameworks will have to include VDOM algorithms. I know this because I remember pushing for this to be supported a few years ago — a nice reminder that the standards are evolving and that nothing stops you from being a small part of the effort.<p>Next up — DOM parts and standardized signals, unified.
This is going to be great for rendering libraries that do keyed loops and for some portal systems.<p>You'll be able to reorder items in a list while preserving focus, without reloading iframes, and keeping audio and video playing.<p>We have a draft PR for support in Lit, and will try to ship that as soon as possible.
Wow! This is actually an amazing feature. Rendering a list of items in which the order can change has always been annoying. I can see this feature greatly improving the situation.
<a href="https://dom.rt.ht/moveBefore" rel="nofollow">https://dom.rt.ht/moveBefore</a> is a playground with 2-way I-O sync!<p>The editor of the playground shows you the live DOM in its editor.
Why isn't it better to redefine insertBefore of an already inserted element to being state-preserving? If I want to kill state, I can do a remove first.
In typical Chrome fashion, they shipped an API that is in status "Specification currently under development in a Working Group"<p>I don't understand the need for this awkward API.<p>Ok, `otherParent.append(existingIframe)` reloads the iframe, but that's just a legacy behavior. Why not toggle the new behavior by calling `existingIframe.holdMyBeer()`? This way I could just continue using .prepend/.append/.before/.after et — which by the way support multiple elements at once, unlike moveBefore.<p>Ridiculous choice, but I'm not even surprised anymore.
Nice, I was just adding <a href="https://github.com/react-grid-layout/react-grid-layout">https://github.com/react-grid-layout/react-grid-layout</a> to a dashboard, where you can drag/re-order charts. I assume this would make the implementation better.
Honestly curious - Does anyone have a use case for this? I tried hard to figure out what this could be used for, but couldn't come up with anything.