trueadm / fragment-node

fragment-node

Why

fragment-node is an experiment to see if there's a hack way of creating a fragment DOM node, similar to DocumentFragment that exists in the DOM tree rather than as an abstraction. By having such a node, it allows us to mutate the DOM tree easily using the existing DOM API whilst ensuring childNodes on the fragment remain. DocumentFragments lose their childNodes once the DocumentFragment is appended to another node.

The core reasoning behind this experiment is to see if React or Inferno can use fragment-node to describe common problems that affect virtual DOM node trees. Such problems include:

const Rows = () => [
    <tr />,
    <tr />,
    <tr />
];

const Table = () => (
    <table>
        <Rows />
    </table>
);

The above example shows a component returning an array of <tr /> nodes from the <Rows /> component. If we were to wrap the output in a <div /> this would break the page as the contents of <table> elements are strict.

Instead libraries like React and Inferno push this problem into userland and educate the user to instead structure their components to have a wrapping root node. In the above example, this would mean they'd have to completely rethink how the <Table /> and ` components work.

How

fragment-node attempts to deal with this problem by providing an alternative to DocumentFragment that works like a typical DOM node, in that it actually gets inserted into the DOM tree and its childNodes remain with it.

It does this by using a placeholder base node (in this implementation it uses an empty CommentNode). It then uses defineProperty and MutationObservers to proxy in features and API methods that you'd typically use on a DocumentFragment.

fragment-node's Issues

Some questions...

Hey @trueadm this is interesting. I have some questions. Haven't tested yet cause on phone...

• would it be better to use comment nodes since adjacent fragment nodes would not get merged during rendering to and html string (for ssr).
• can this accomodate fragments-in-fragments? adjacent fragments?

a more useful demo might be

table
  tbody
    tr
    tr
    tr
    tr
  tbody
    tr
    tr
    tr
    tr
  tbody
    tr
    tr
    tr
    tr
  tbody
    tr
    tr
    tr
    tr

where every 2 adjacent tbody elems are a fragment and every 2 adjacent tr elems are a fragment.

this would go a long way towards demonstrating general utility.