Re: [whatwg/dom] Proposal: a DocumentFragment whose nodes do not get removed once inserted (#736)

robbiespeed left a comment (whatwg/dom#736)

@rniwa DOM Parts seems overkill/overly complex. Having to stage changes for commit is more work than simply making the DOM changes, and it's not clear there would be any perf benefit, not to mention the added complexity of `PartGroup` to avoid needing to run each parts commit individually. Marking dynamic areas using the Declarative API has very little benefit over using `data-` attributes or ids, which have more flexibility in retrieving the active areas for hydration/update. In general I don't think the web needs a standard for html template syntax.

Sibling/partial `ChildNodeParts` in DOM Parts still appears to be an unanswered question, and that's what a persistent fragment would solve.

The benefit of this proposal vs DOM Parts is a more unified interface across a persistent fragment and nodes. This helps with framework code because if a fragment is a node or has the same interface you don't need to have 2 paths for handling a dynamic group of nodes vs a single node, this is especially tricky in dynamic list rendering. Similarities with existing APIs also means less to learn.

I'm very sceptical of this proposal adding any additional DOM syntax, that seems unnecessary just as the DOM Parts syntax does. If SSR is a concern it's easy enough to identify the bounds of the fragment using comment nodes and a `data-` attribute on the parent to describe the position.

I also think it's unnecessary for the fragment to have a direct representation in the Document, adding a fragment to the document should behave like a DocumentFragment (adds the children directly to the parent in the document) with the difference being that it wont remove the nodes from the fragment. As a consequence of this direct children in a fragment that are not a child of a element (attached to document or a non-attached element) yet should have `parentNode` set to `null`. Ideally `previous/nextSibling` on the fragment would use the `first/lastChild` siblings respectively.

There is an issue of empty fragments as there would be nothing to mark their place. The simplest answer there is that when a fragment becomes empty it is no longer attached to any element, and attempting to attach an empty fragment would be a no-op. This would be trivial to work around because if anyone wanted the fragment to remain attached they could replace children with a comment or empty text node. Another option would be that fragments must always have a static marker node specified at creation time, in the SSR hydration scenario this could be one of the comment nodes used to separate fragments.

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

Message ID: <whatwg/dom/issues/736/2759449820@github.com>