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

rniwa left a comment (whatwg/dom#736)

> 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.

How do you suppose we do server side rendering without it?

> 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.

Hm... are you imaging that during hydration we'd move the nodes from the regular nodes to this `NodeGroup` object somehow? It's unclear to me what kind of use of comments and data attributes will address server-side rendering use cases.

> 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 an 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.

That would be a major departure from the current model of DOM nodes, and it would pose major implementation challenges.

> 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.

This is why `NodeGroup` being a part of DOM tree is an appealing alternative. Then you can easily insert an empty fragment / group. I'm not necessarily advocating for one approach or the other but being able to handle empty group case without much complexity seems important.

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

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