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

Catching up with the conversation and adding Angular's perspective here.

tl;dr;
* very supportive of the effort, definitively see the issues of loosing state when moving DOM nodes around;
* strongly prefer a new, imperative DOM API (`node.moveBefore(...)` or similar);
* not _requiring_ re-parenting in the core of the framework;
* would like to see general "preserve DOM state" considered and not have it limited to IFrames only;
* not too concerned with the breaking changes as we see the current non-preserving-state behaviour as problematic - some backward compatibly escape hatch might be useful but not required.

Given the above I think that Angular's position is very well aligned with the [current direction](https://github.com/whatwg/dom/issues/1255#issuecomment-2025931322) of the proposal 🎉 

Some more details below.

## Background

We regularly see issues caused by the "logical move" operation implemented as a pair of remove + add and loosing state as the consequence. This mostly comes up when using loops ([@for](https://angular.dev/api/core/@for) or [ngFor](https://angular.dev/guide/directives#listing-items-with-ngfor)) that re-order lists - those loops have perfect understanding / distinction of insert vs. move so loosing state with moves is a real concern. We mostly see people complain about state loos in form controls (selection, focus) and iframes. 

Despite seeing those issues we never attempted implementing any work-around but rather were counting on a solution from the platform - in this sense very supportive of those efforts.

## API proposal

### declarative vs. imperative

We mostly move nodes around when re-ordering list items in loops. Those framework constructs are executing JavaScript logic to understand lists re-ordering and move DOM nodes around accordingly. In this sense this logic is already very imperative and thus we would require imperative API to make use of the new platform capability.  Declarative attributes could be used to _opt out_ of the state preserving behaviour but using them to indicate that a state of a given node should be preserved would be problematic - we would have to pretty much add those new attributes to all the nodes created by the framework.

### API shape

Technically speaking most of the proposed API signatures (`parent`, `parent.insertBeforeAtomic`, `parent.insertBefore(..., {atomic: true})`, `node.moveBefore(...)` ) would work for us but `node.moveBefore(...)` seems like a cleanest and preferred shape.

### listing state to preserve

We would rather _not_ explicitly list state to preserve as proposed with `parent.insertBeforeAtomic(div, reference, {preserve: 'iframecontent,selection,foo'})` - this would require us to keep adding new capabilities as they come around, track those and consider breaking changes. Would prefer the approach where we decide, on the platform level on "state that makes sense to preserve".

### re-parenting

Not strictly necessary in the core of the framework (we move nodes under the same parent) so could see a 2-phase approach were this simpler use-case is tackled first.

## Breaking changes

We do understand that the existing code might somehow depend on the fact that state is reset when the corresponding DOM nodes are moved but we see this more like a bug.

## Other comments

The framework is usually moving a set of nodes so would love to see some thinking on this - similar consideration to the one expressed by @WebReflection in https://github.com/whatwg/dom/issues/1255#issuecomment-1944590622 

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

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