- From: Isiah Meadows <notifications@github.com>
- Date: Thu, 04 Jan 2018 00:15:17 +0000 (UTC)
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/554@github.com>
*Note: this is purely for the DOM - HTML syntax for live fragments are beyond the scope of this proposal.* "Dead" document fragments are useful for templates. They hold static trees and everything, and automagically disappear so appending them is idempotent. "Live" fragments would make lives easier for anyone who deals with componentized architectures that aren't called "web components": - Currently, a *lot* of code in vdom libraries with fragment support deal with managing subtrees (trust me - I'm one of the maintainers for one), and they have to work around the fact no native equivalent of this exists: ```jsx // Using React JSX here for familiarity // In a child component return <React.Fragment> <div className="foo"></div> <div className="bar"></div> </React.Fragment> // In a parent component return <div className="child"> <ChildComponent foo={bar} /> <ChildComponent foo={baz} /> </div> // The actual tree return <div className="child"> <React.Fragment> <div className="foo"></div> <div className="bar"></div> </React.Fragment> <React.Fragment> <div className="foo"></div> <div className="bar"></div> </React.Fragment> </div> ``` - Ember and Vue could potentially use a "live" fragment to *dramatically* accelerate their `if` (without `else`) bodies. - It'd make it possible for smaller libraries to define and return their own "live" fragments rather than have to wrap an *entire* element to themselves all the time. As for whether this could be reliably done in a library, I've tried somewhat (no code available), and I found I had to basically reinvent about 90% of the `Node` interface and do some pretty extensive, kludgy parent/child tracking just to implement the basics. It'd be way easier if browsers implemented this natively, as it would probably consist of maybe a new type and a couple properties/methods, and it's something that they could integrate with their rendering pipeline. ----- Here's my first shot at designing an API: - `const frag = new SubtreeFragment()` - Create a new live fragment. - `SubtreeFragment` is a subtype of `Node`, not `DocumentFragment`. - `Node.SUBTREE_FRAGMENT_NODE` needs added. - `frag.nodeType` is defined to be `Node.SUBTREE_FRAGMENT_NODE`. - When a subtree fragment is added, it is invisible from the viewpoint of selectors. (This will need spec'd correspondingly within the CSS selector spec.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/554
Received on Thursday, 4 January 2018 00:15:59 UTC