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

WebReflection left a comment (whatwg/dom#736)

@robbiespeed example is spot on but just one out of many ... a basic *todo* `<li>` based list could have 2 groups: done and still to be done. Sorting these two groups will be a single `insertBefore` operation: the one on top is the one to `insertBefore` the other ... and that's it. Moving nodes from done to *to be done* is also a single `moveBefore` operation plus, because the group doesn't have ay constraints on its content, nodes within groups can be easily shuffled or spread around the single parent and re-ordered by just appending these into each related group when desired.

If needed though, I could link some obvious P/React usage of the fragment primitive because everything that `<></>` covers in the P/React world is what *NodeGroup* could end up covering too.

About DOM Parts: it's been a very long time I've heard about it but never took the time to fully investigate what it does. To mee it was born to solve the spread attributes parts within their content which is a not interesting use case for P/React (or JSX) and neither for other template literal based libraries where the constraint is simple: you cannot change a single attribute part because at the end of the day the whole attribute changes anyway so that in JSX you can't have `<div class="a {runtime}" c />`, it's either `<div class={`a ${runtime}` c} />` or it throws out of the box and same goes for my own libraries and others that kept it simple.

However, if DOM Parts can handle also internal nodes with similar ease, or it could be improved in a way that's possible to obtain what *NodeGroup* does, I fully agree there shouldn't be any overlap, but at the same time this primitive could be already used and be handy without all the *Parts* around so that *KISS* was my initial approach to solve a single, yet common, use case without making it any more complex than it needs to be (meaning ignoring entirely attributes, as that's a whole different story).

I hope what @FrameMuse said makes sense too and I do really hope either as primitive a part or as part of DOMParts, the ability to group nodes and have "*connected fragments*" will soon land as standard API.

Thanks to everyone for contributing, joining the call, sharing ideas and concerns though, that's how I was expecting the meeting to go indeed.

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

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