"virtualize" method for creating virtual DOM nodes modelled after the real DOM.

[marcelklehr]

Hello,

I'm very interested in DOM-diffing and was also intrigued by the apparent huge potential hidden in reacts diff algorithm and I'd love to see this project grow into a solid and slick tool, that I would very much like to myself! ;)

Additionally, I wanted to propose a project(realDOMNode) method ("virtualize" is prolly a better name), that will create a virtual DOM from a a real DOM node. This would be very useful together with contenteditable / HTML WYSIWYG editors (e.g. so one could create a diff to get the changes a user made).

[Raynos]

Recommended approach!

Write a module called virtual-dom-project that exports a project function. It can depend on virtual-dom and create a new virtual dom node!

[Matt-Esch]

The inverse is important to syncing up server side rendered html. I presume mapping Element.attributes / Element.tagName and Element.childNodes is sufficient?

At some point we want component boundaries based on lazily computed subtrees, so we will need a sensible inference method in the DOM for these boundaries.

[Raynos]

Element.attributes and vdom.properties are not the same.

See properties vs attributes. If you want properties in the virtual dom then you have to unpack all the properties on the real dom element and ignores its attributes.

Having the inverse of render in this repo is cool too.

[Matt-Esch]

Ok, I am sufficiently convinced that for this to be useful generically it's going to take a non-trivial amount of work to standardize read/write access to DOM properties. I initially approached this from the use case of turning static HTML into a tree for patching, where only attributes are the only state definition.

There is only a certain amount of state that we are interested in. For example, the focus state of an element is not our concern. The DOM is allowed to persist some state without our care, and it's useful. We would need to define a property mapping to expunge any host objects we might read, and anything that may not be relevant or important when it comes to producing a structure that renders in a way that looks the same.

[Raynos]

There might actually be value in a well documented whitelist of all properties you can pass to h or to virtual-dom-node and it will be rendered properly.

Maybe on a wiki page, this will be useful for documenting exactly what we can deal with. We can then write project and render test for everything we claim can be modelled within the virtual-dom

[Matt-Esch]

This is verging slightly off topic, but yes, a list of supported properties will make this easier, not only in order to implement the property diffing algorithm but to read values out of the DOM.

[Matt-Esch]

This should be a separate module. Any help appreciated.