An implementation of fragments exist as DocumentFragment but these share a weak reference with their children, resulting in the Node loosing its children once you append/insert the Node.
Is it possible to create a new Node type that would resemble DocumentFragment but maintain a strong reference between it and its children when appending/inserting/removing the Node, for example an API for this might look like document.createFragment()
You can use document.importNode(fragment, true) to generate new nodes without removing the old ones. This is particularly useful if you’re using <template> to generate new nodes.
I can’t see a need for a new createFragment API that isn’t already handled by this functionality.
The idea is for a persistent DocumentFragment like Node that acts like a Element Node but has the opaque nature of DocumentFragment.
I don’t think importNode touches the same function a FragmentNode would cover; A FragmentNode would maintain the state of its children and move/remove its children when it is itself moved/removed.
Can you describe how FragmentNode would handle an individual child being removed from the DOM, while the rest of the fragment’s children somehow remain?
Also unlike family trees, child nodes in the DOM can only ever have one parent. If a FragmentNode has a bunch of child nodes, those child nodes can’t possibly refer back to the FragmentNode without the introduction of a new property because parentNode and parentElement would have to refer to their parent nodes in the DOM tree once elements were added.
I’m highly skeptical that any of this is necessary or provides a solution that is otherwise challenging to handle with plain javascript. Can you show an example use case where FragmentNode is a significant improvement over the existing DOM APIs?
Given a fragment of nodes [3, 4, 5] within a larger list of childNodes [1, 2, [3, 4, 5], 6]; Consider the fragment is within a <div> node, the <div> node would have the childNodes 1, 2, 3, 4, 5, 6 where between 3-to-5 marked the implied boundary of the fragment.
Removing a child in the fragment i.e 4 will result in the transitioning the fragments parentNodes(div) childNodes to 1, 2, 3, 5, 6 and the fragment to 3, 5. As far as the fragments children are concerned their parentNode is the fragments parentNode and as far as the parentNode’s childNodes are concerned the fragments childNodes are also it’s childNodes; As such removing the fragment would also result in the parentNode(div) loosing the childNodes marked under the fragments boundary.
As such the FragmentNode forms a set of childNodes that you can used as a references to insert/remove/append/clone a set/collection of related Nodes represented by a transparent boundary that is the FragmentNode.
Like DocumentFragment this can be implemented in user-land but there-in comes the guarantee and convenience of a single transparent FragmentNode structure that can manage this for you.
I’m still unclear, what actual problem is this API attempting to solve? The example given sounds like it can be replicated with an object that contains an array of node references.
Creating a collection of nodes that you can apply Move/Insert/Append operations on as a set. This can be implemented in user-land, the proposal is for an a API that makes this into a native NodeType resembling DocumentFragment.
This is a description of what your proposed API would do, not a description of the problem your API would solve.
This is a big red flag to me. What it tells me is you have a solution looking for a problem. If that’s not the case, please by all means disprove me by providing evidence.