Enhancement: support diffing the real DOM with a virtual DOM about morphdom HOT 7 CLOSED

@patrick-steele-idem I created a https://github.com/DylanPiercey/vdo to create a lightweight (html focused) vdom. Would this change make something like that work? What exactly needs to be done to achieve this?

from morphdom.

Hey @DylanPiercey, do the virtual DOM nodes created by vdo implement the following properties and methods associated with real DOM nodes?:

• node.firstChild
• node.tagName
• node.nextSibling
• node.attributes
• node.nodeType
• node.nodeValue

If so, then the diffing/patching would work even if the target DOM tree is a tree of virtual vdo nodes. The only thing that would need to change to morphdom is that the virtual DOM nodes would need to be upgraded to real DOM nodes if they need to be moved into the DOM.

from morphdom.

@patrick-steele-idem currently the vnodes are a bit different but I'd probably switch if things go well with this library.

Do you think that the vnodes should implement something like a #toDOM which would be called by morphdom or are you thinking that morphdom will somehow detect that a node is virtual and manually convert it to a real node?

from morphdom.

@DylanPiercey I looked at the virtual-dom docs again.

They have a createElement function which converts vdom to dom. We could have an option property hold the function that upgrades a vdom tree. If we did that for the other methods mentioned above (similar to the hooks virtual-dom uses) we don't need the vdom tree to implement that interface.

A plugin author could create all of the methods needed and mix them in with options passed to morphdom.

Morphdom internal pseudo code:

if !node#nodeType
then options.nodeType(node)
...

from morphdom.

yo-yo and choo make use of a virtual DOM through shama/bel which translates html template strings into raynos/global calls, which creates virtual elements using raynos/min-document and delegating to the related dom-* files in the repo.

In production we use the yo-yoify transform which changes all element creation calls from yo-yo, bel and choo into document.createElement and equivalents. Benchmarks have shown that using yo-yoify would speed up the tested TodoMVC application by 2x, but this was supposedly mostly due to removing the template string creation step.

My concern with morphdom adding virtual dom node creation is that the scope of the package would creep beyond just being good at diffing. I feel like having wrappers such as yo-yo available is great, because they add opinions on top of a core we can share.

@patrick-steele-idem I'm not sure what you've got in mind for this, but I'd be keen to hear. I figured I'd go ahead and explain what we've been building on top of morphdom so far, because it sounds like it's quite similar to what is being proposed in this thread. Thanks! ✨

from morphdom.

@yoshuawuyts Rest assured that morphdom will not become any more complex when introducing support for diffing real DOM nodes with virtual DOM nodes 😄

The plan is to require that the virtual DOM nodes be API compatible with real DOM nodes for the minimal subset of API methods and properties required by morphdom. The only extra code that is required to support diffing a real DOM node with a virtual DOM node is that a virtual DOM node must be upgraded to a real DOM node before inserting it into the DOM.

I have just published a virtual DOM implementation that meets morpdom's requirements: marko-vdom

You could use marko-vdom with yo-yo/bel/choo if you would like. The only reason marko-vdom has marko in its name is that marko-vdom was designed as a compilation target for marko (the API is not user friendly, but it is super fast and great for use with compilers/transpilers). marko-vdom has 100% code coverage and we will of course follow semantic versioning.

I will be pushing some new code for morphdom very soon (probably today) and you will see that the changes to support DOM <-> VDOM diffing/patching are minimal.

from morphdom.

Fixed by PR #83

from morphdom.