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.
I'm the developer of react-reverse-portal, this will definitely be a real help!
Iframes particularly have always been a pain point, as people often want to reparent them to move things around the DOM, but they always reload completely when you do so which causes all sorts of issues. This new API says it explicitly _doesn't_ reload iframes, so we'll be able to drop that caveat immediately (for supporting browsers, but hopefully Safari/FF will follow suit soon). Looks great!
This will need refactoring before being enabled, and possibly might not be enabled at all because it would introduce a perf regression do to the necessary checks to branch between moveBefore or insertBefore.
This was brought up multiple times to the html spec authors, but no changes were made.
https://github.com/facebook/react/pull/32036
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.
https://github.com/facebook/react/issues/12247 (2018-2020) describes some of the use cases, with one partial solution being https://github.com/httptoolkit/react-reverse-portal - the conversation around caveats of these approaches would be entirely different now!