Ecosyste.ms: Awesome

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

Awesome Lists | Featured Topics | Projects

https://github.com/paf31/purescript-sdom

An experiment in replacing the virtual DOM and avoiding diffing
https://github.com/paf31/purescript-sdom

Last synced: 3 months ago
JSON representation

An experiment in replacing the virtual DOM and avoiding diffing

Awesome Lists containing this project

README 

        
# purescript-sdom



An experiment in replacing the virtual DOM and avoiding diffing.



- [Module Documentation](generated-docs/)

- Examples

  - [Counter](examples/counter)

  - [Select](examples/select)

  - [Task List](examples/todo)

  - [Async](examples/async)

  - [Tree](examples/tree) (higher-order component)

  - [Canvas](examples/canvas) (third-party component)



## Motivation



The virtual DOM (VDOM) has become a very popular approach to developing applications

in the browser, popularized by libraries like React. A simplified VDOM approach can be

summarized briefly as follows:



- Choose a type `state` of _application states_.

- Write a function `state -> VDOM` from application states to a virtual DOM

  representation of the UI.

- Each time we reach a new state, use a function `diff :: VDOM -> VDOM -> Patch` to

  compute the changes to the rendered virtual DOM.

- Use a function `Patch -> Eff (dom :: DOM) Unit` to _apply_ those changes to

  the real DOM.



The VDOM approach has many benefits. However, many web apps which use a

VDOM don't actually require one.



Consider something like a web form which might contain text inputs and validation

messages. If you didn't have a virtual DOM, you would just lay out the form statically,

set the initial attributes and text values, and add event handlers to update them.

The elements themselves would never change.



A VDOM approach in this case might be considered overkill - why should I have to

diff two trees of components in order to update a simple label, when I can always

easily figure out which label to update.



A key benefit of the VDOM is that it hides the complexity of the DOM API behind

a simpler API with a clean denotation: an application is a function from states

to a conceptual representation of the UI. However, operationally it is very heavy.

The potential problem is that the `diff` function above might be quite expensive

to compute. With well-chosen keys on every node, it might be possible to tune this

computation, but there are other options available.



This library introduces the SDOM, or "static DOM". The idea is that by restricting

components so that the "shape" of the UI becomes static, we can keep the clean

denotation of the VDOM approach, but simplify the operational side dramatically.

The SDOM consists of a static tree of components, with only the leaves (text nodes and

attributes) changing over time. The SDOM approach also allows for limited forms of dynamic

behavior, such as a component which renders a (uniform) array of subcomponents.



In practice, this is not so much of a restriction, and the limited form of dynamic behavior

is enough to emulate most common UI patterns. Indeed, working with the SDOM is quite

reminiscent of template-based approaches to UI development, but keeping the "one

way binding" approach which is commonly associated with the VDOM.



### More

For a more extensive motivation of the SDOM approach, an explanation of the 

underlying approach and how it was developed, you may want to check out this 

[blog post](http://blog.functorial.com/posts/2018-03-12-You-Might-Not-Need-The-Virtual-DOM.html).