Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/WebReflection/linkedom

A triple-linked lists based DOM implementation.
https://github.com/WebReflection/linkedom

dom ssr web

Last synced: 29 days ago
JSON representation

A triple-linked lists based DOM implementation.

Awesome Lists containing this project

README 

        
# 🔗 linkedom



[![Downloads](https://img.shields.io/npm/dm/linkedom.svg)](https://www.npmjs.com/package/linkedom) [![Build Status](https://travis-ci.com/WebReflection/linkedom.svg?branch=main)](https://travis-ci.com/WebReflection/linkedom) [![Coverage Status](https://coveralls.io/repos/github/WebReflection/linkedom/badge.svg?branch=main)](https://coveralls.io/github/WebReflection/linkedom?branch=main)



**Social Media Photo by [JJ Ying](https://unsplash.com/@jjying) on [Unsplash](https://unsplash.com/)**



### This is not a crawler!



LinkeDOM is a [triple-linked list](#data-structure) based DOM-like namespace, for DOM-less environments, with the following goals:



  * **avoid** maximum callstack/recursion or **crashes**, even under heaviest conditions.

  * guarantee **linear performance** from small to big documents.

  * be **close to the** current **DOM standard**, but [not too close](https://github.com/WebReflection/linkedom#faq).



```js

import {DOMParser, parseHTML} from 'linkedom';



// Standard way: text/html, text/xml, image/svg+xml, etc...

// const document = (new DOMParser).parseFromString(html, 'text/html');



// Simplified way for HTML

const {

  // note, these are *not* globals

  window, document, customElements,

  HTMLElement,

  Event, CustomEvent

  // other exports ..

} = parseHTML(`

  

  

    

      Hello SSR

    

    

      

        

        

          Submit

        

      

    

  

`);



// builtin extends compatible too 👍

customElements.define('custom-element', class extends HTMLElement {

  connectedCallback() {

    console.log('it works 🥳');

  }

});



document.body.appendChild(

  document.createElement('custom-element')

);



document.toString();

// the SSR ready document



document.querySelectorAll('form, input[name], button');

// the NodeList of elements

// CSS Selector via CSSselect

```



### What's New



  * in `v0.11` a new `linkedom/worker` export has been added. This works with [deno](https://deno.land/), Web, and Service Workers, and it's not strictly coupled with NodeJS. Please note, this export does not include `canvas` module, and the `performance` is retrieved from the `globalThis` context.



### Serializing as JSON



*LinkeDOM* uses a blazing fast [JSDON serializer](https://github.com/WebReflection/jsdon#readme), and nodes, as well as whole documents, can be retrieved back via `parseJSON(value)`.



```js

// any node can be serialized

const array = toJSON(document);



// somewhere else ...

import {parseJSON} from 'linkedom';



const document = parseJSON(array);

```



Please note that *Custom Elements* won't be upgraded, unless the resulting nodes are imported via `document.importNode(nodeOrFragment, true)`.



Alternatively, `JSDON.fromJSON(array, document)` is able to initialize right away *Custom Elements* associated with the passed `document`.



### Simulating JSDOM Bootstrap



This module is based on [DOMParser](https://developer.mozilla.org/en-US/docs/Web/API/DOMParser) API, hence it creates a *new* `document` each time `new DOMParser().parseFromString(...)` is invoked.



As there's *no global pollution* whatsoever, to retrieve classes and features associated to the `document` returned by `parseFromString`, you need to access its `defaultView` property, which is a special proxy that lets you get *pseudo-global-but-not-global* properties and classes.



Alternatively, you can use the `parseHTML` utility which returns a pseudo *window* object with all the public references you need.



```js

// facade to a generic JSDOM bootstrap

import {parseHTML} from 'linkedom';

function JSDOM(html) { return parseHTML(html); }



// now you can do the same as you would with JSDOM

const {document, window} = new JSDOM('
Hello LinkeDOM 👋
');

```



## Data Structure



The triple-linked list data structure is explained below in [How does it work?](#how-does-it-work), the [Deep Dive](./deep-dive.md), and the [presentation on Speakeasy JS](https://www.youtube.com/watch?v=PEESaD7Qkxs).



## F.A.Q.



  Why "not too close"?

  



*LinkeDOM* has zero intention to:



  * implement all things *JSDOM* already implemented. If you need a library which goal is to be 100% standard compliant, please [use JSDOM](https://github.com/jsdom/jsdom) because *LinkeDOM* doesn't want to be neirly as bloated nor as slow as *JSDOM* is

  * implement features not interesting for *Server Side Rendering*. If you need to pretend your NodeJS, Worker, or any other environment, is a browser, please [use JSDOM](https://github.com/jsdom/jsdom)

  * other points listed, or not, in the followung *F.A.Q.s*: this project will always prefer the minimal/fast approach over 100% compliant behavior. Again, if you are looking for 100% compliant behavior and you are not willing to have any compromise in the DOM, this is **not** the project you are looking for



That's it, the rule of thumb is: do I want to be able to render anything, and as fast as possible, in a DOM-less env? *LinkeDOM* is great!



Do I need a 100% spec compliant env that simulate a browser? I rather use *cypress* or *JSDOM* then, as *LinkeDOM* is not meant to be a replacement for neither projects.



  



  Are live collections supported?

  



The *TL;DR* answer is **no**. Live collections are considered legacy, are slower, have side effects, and it's not intention of *LinkeDOM* to support these, including:



  * `getElementsByTagName` does not update when nodes are added or removed

  * `getElementsByClassName` does not update when nodes are added or removed

  * `childNodes`, if trapped once, does not update when nodes are added or removed

  * `children`, if trapped once, does not update when nodes are added or removed

  * `attributes`, if trapped once, does not update when attributes are added or removed

  * `document.all`, if trapped once, does not update when attributes are added or removed



If any code you are dealing with does something like this:



```js

const {children} = element;

while (children.length)

  target.appendChild(children[0]);

```



it will cause an infinite loop, as the `children` reference won't side-effect when nodes are moved.



You can solve this in various ways though:



```js

// the modern approach (suggested)

target.append(...element.children);



// the check for firstElement/Child approach (good enough)

while (element.firstChild)

  target.appendChild(element.firstChild);



// the convert to array approach (slow but OK)

const list = [].slice.call(element.children);

while (list.length)

  target.appendChild(list.shift());



// the zero trap approach (inefficient)

while (element.childNodes.length)

  target.appendChild(element.childNodes[0]);

```



  



  Are childNodes and children always same?

  



**Nope**, these are discovered each time, so when heavy usage of these *lists* is needed, but no mutation is meant, just trap these once and use these like a frozen array.



```js

function eachChildNode({childNodes}, callback) {

  for (const child of childNodes) {

    callback(child);

    if (child.nodeType === child.ELEMENT_NODE)

      eachChildNode(child, callback);

  }

}



eachChildNode(document, console.log);

```



  



## How does it work?



All nodes are linked on both sides, and all elements consist of 2 nodes, also linked in between.



Attributes are always at the beginning of an element, while zero or more extra nodes can be found before the end.



A fragment is a special element without boundaries, or parent node.



```

Node:             ← node →

Attr:       ← attr →          ↑ ownerElement?

Text:       ← text →          ↑ parentNode?

Comment:    ← comment →       ↑ parentNode?

Element:    ← start ↔ end →   ↑ parentNode?



Fragment:  start ↔ end



Element example:



        parentNode? (as shortcut for a linked list of previous nodes)

            ↑

            ├────────────────────────────────────────────┐

            │                                            ↓

  node? ← start → attr* → text* → comment* → element* → end → node?

            ↑                                            │

            └────────────────────────────────────────────┘



Fragment example:



            ┌────────────────────────────────────────────┐

            │                                            ↓

          start → attr* → text* → comment* → element* → end

            ↑                                            │

            └────────────────────────────────────────────┘

```



If this is not clear, feel free to **[read more in the deep dive page](./deep-dive.md)**.



### Why is this better?



Moving *N* nodes from a container, being it either an *Element* or a *Fragment*, requires the following steps:



  * update the first *left* link of the moved segment

  * update the last *right* link of the moved segment

  * connect the *left* side, if any, of the moved node at the beginning of the segment, with the *right* side, if any, of the node at the end of such segment

  * update the *parentNode* of the segment to either *null*, or the new *parentNode*



As result, there are no array operations, and no memory operations, and everything is kept in sync by updating a few properties, so that removing `3714` sparse `
` elements in a *12M* document, as example, takes as little as *3ms*, while appending a whole fragment takes close to *0ms*.



Try `npm run benchmark:html` to see it yourself.



This structure also allows programs to avoid issues such as "*Maximum call stack size exceeded*" (basicHTML), or "*JavaScript heap out of memory*" crashes (JSDOM), thanks to its reduced usage of memory and zero stacks involved, hence scaling better from small to very big documents.



### Are *childNodes* and *children* always computed?



As everything is a `while(...)` loop away, by default this module does not cache anything, specially because caching requires state invalidation for each container, returned queries, and so on. However, you can import `linkedom/cached` instead, as long as you [understand its constraints](https://github.com/WebReflection/linkedom#cached-vs-not-cached).



## Parsing VS Node Types



This module parses, and works, only with the following `nodeType`:



  * `ELEMENT_NODE`

  * `ATTRIBUTE_NODE`

  * `TEXT_NODE`

  * `COMMENT_NODE`

  * `DOCUMENT_NODE`

  * `DOCUMENT_FRAGMENT_NODE`

  * `DOCUMENT_TYPE_NODE`



Everything else, at least for the time being, is considered *YAGNI*, and it won't likely ever land in this project, as there's no goal to replicate deprecated features of this aged Web.



## Cached VS Not Cached



This module exports both `linkedom` and `linkedom/cached`, which are basically the exact same thing, except the cached version outperforms `linkedom` in these scenarios:



  * the document, or any of its elements, are rarely changed, as opposite of frequently mutated or manipulated

  * the use-case needs many repeated *CSS* selectors, over a sporadically mutated "*tree*"

  * the generic DOM mutation time is *not* a concern (each, removal or change requires a whole document cache invalidation)

  * the *RAM* is *not* a concern (all cached results are held into *NodeList* arrays until changes happen)



On the other hand, the basic, *non-cached*, module, grants the following:



  * minimal amount of *RAM* needed, given any task to perform, as nothing is ever retained on *RAM*

  * linear fast performance for any *every-time-new* structure, such as those created via `importNode` or `cloneNode` (i.e. template literals based libraries)

  * much faster DOM manipulation, without side effect caused by cache invalidation



## Benchmarks



To run the benchmark locally, please follow these commands:



```sh

git clone https://github.com/WebReflection/linkedom.git



cd linkedom/test

npm i



cd ..

npm i



npm run benchmark

```