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

While on the subject of atomic reparenting, I would like to point out a stumbling block that would continue to cause non-atomic reparenting: `DocumentFragment`s.

In many real-world use-cases currently, `DocumentFragment`s are used purely with the intent to gather up and pre-arrange a collection of maybe-connected nodes to submit to batch reparenting operations (`appendChildren`/`replaceChildren`). Yet in order to do this, all the nodes must first be *non-*atomically reparented *to* the `DocumentFragment`. And because `DocumentFragment`s can't themselves be connected to the DOM (vis. "DOM Parts"), there's no way for an operation that involves temporarily assigning nodes to live under a `DocumentFragment`, to ever be atomic.

IMHO a fully-general solution to atomic element reparenting, needs to deal with the case where the developer's goal is to reparent a *batch* of nodes, without any of those nodes ever becoming disconnected.

I'm not totally sure what a solution that addresses that use-case could look like. Some thoughts:

* Maybe a `DocumentFragmentView` that acts like a DOM node — in terms of being accepted by DOM APIs anywhere a `DocumentFragment` is accepted — but is really just a data structure, just holding borrowed references to nodes rather than reparenting them under itself. (Alternately, make `DocumentFragment`s themselves able to act like this if you set some property on them.)
* Or maybe a `DOMAtomicMutationTransaction` operation, either:
  * implicit, existing for the lifetime of a callback submitted to a `document.atomicMutation` call
  * or reified as an accessible object returned by e.g. `document.beginAtomicMutation`, then passable as an option into Node mutation operations, and then offering a `commit` method

I mention these potential approaches here not because I think they're particularly well-thought-out / beyond need for further refinement under WICG; but rather because these ideas seem to have a common thread. It would seem that any solution that addresses the "atomic reparenting despite a use-case that would warrant use of `DocumentFragment`" problem, seems to also be a fully-general solution for atomic reorder/reparent generally, batched or not.

- In the `DocumentFragmentView` case, the semantics could be specified such that mutation operations that consume a `DocumentFragmentView` are always performed atomically on the contents of the view. So, rather than changing any existing APIs to introduce atomic variants, anyone who wants atomic reorder/reparent even a single node could do it by wrapping the node first in a `DocumentFragmentView` and then (re)placing it somewhere.
- In the `DOMAtomicMutationTransaction` case, single operations could be wrapped in a transaction just as well as multiple operations could. (If using the reified form, `document.beginAtomicMutation` could have an optional parameter `singleOperation`, or an alternate form `document.singleAtomicMutation`, where in either case, you don't need to call `commit` because it's done implicitly at the end of the consuming operation — allowing the caller to just do e.g. `node.appendChild(newChild, document.singleAtomicMutation())`.

Because these approaches seem to be general, I would suggest paying attention to the "atomic reparenting despite a use-case that would warrant use of `DocumentFragment`" problem as a generator for potential approaches for the higher-level reparenting/reordering API-design problem. (Feel free to ignore the particular potential approaches outlined above, though; I just wanted to use them to make this point.)

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

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