Use Matt-Esch/virtual-dom

[alexmingoia]

This module could benefit a lot from the ecosystem and work done around virtual-dom. It'd be nice to see the vdom stuff separated out so this is just a component/view implementation.

[anthonyshort]

Yeah I saw that, but we didn't use it because there was very little documentation around how it worked, especially the concept of widgets. Looking through the code, it was difficult to see how to implement anything with it.

There's a lot of consider when creating components around a virtual tree. At first I couldn't understand why FB kept the diffing algorithm tied to the component/rendering system, but after building one it actually makes things a lot simpler.

[alexmingoia]

This will probably be added to the virtual-dom docs soon https://github.com/littleloops/virtual-dom-docs-wip

You just need to use a hook to add your events when elements are created from the vnodes... also take a look at http://github.com/Raynos/mercury for how virtual-dom modules can be used.

[anthonyshort]

It's definitely something I'd love to see happen, but the architecture is solid and clean at the moment so we probably won't switch it just now. If those docs had been around earlier it might be different :)

Having a single library that is the virtual-dom implementation would definitely be valuable to everyone.

[Raynos]

Documentation:

• https://github.com/littleloops/virtual-dom-docs-wip
• https://github.com/Raynos/mercury/blob/master/docs/hooks.md
• https://github.com/Raynos/mercury/blob/master/docs/thunks.md
• https://github.com/Raynos/mercury/blob/master/docs/faq.md

Is there anything missing from the documentation other then "having it all in one place" ?

[Raynos]

@anthonyshort

it should be noted that @Matt-Esch wrote virtual-dom because there was no good React documentation of internals.

It's amusing that virtual-dom itself also suffers the "there is no good documentation problem"

Remember to close the loop by writing solid documentation for deku itself.

[anthonyshort]

Those docs are really useful and I really love the ideas behind that project. We wanted to be less generic by including the "components" within the virtual-dom implementation which is where the ideas conflicted.

As a brief aside, the subtree re-rendering technique (which is not implemented) says that recreating the entire virtual tree from the top to the bottom when anything changes is a bad idea. Instead if something changes we should try and only recreate the component that has changed (and it's children). This is not implemented because having a state <-> component mapping is hard to do whilst keeping purity, immutability & referential transparency.

That's basically how deku works. Components/sub-trees mark themselves as dirty and are re-rendered on the next pass, kind of like React. This is the main difference that would make it hard to use virtual-dom as the implementation behind the scenes. We've coupled the idea of sub-trees and components with the diffing/rendering, because like you said, it's super hard to do while keeping it pure.

I did this because I wanted to make the API for the end-user was extremely simple. Mercury looks great, but the API just isn't easy to use.

[Raynos]

@anthonyshort

performance and simplicity reasons are one of the reasons for not allowing subtree re-rendering.

Another reason is we just don't want this feature since we want the state atom to be a single serializable, deterministic thing from which the entire application can be reloaded.

You should ask yourself what happens when someone does

function render(dom) {
  var c = ButtonComponent({ ... })

  return dom('div', [
    c, c, c
  ])
}

or

var c2 = ButtonComponent({ ... })

function render(dom) {
  var c = ButtonComponent({ ... })

  return dom('div', [
    c, c2, c, c2
  ])
}

This is one of the reasons we avoided sub-tree re-rendering.

[Matt-Esch]

it should be noted that @Matt-Esch wrote virtual-dom because there was no good React documentation of internals.

It's amusing that virtual-dom itself also suffers the "there is no good documentation problem"

I wrote virtual-dom because there is only one piece of documentation I need but couldn't find: readable source code.

[anthonyshort]

@Raynos ButtonComponent() is just a node in the tree not an instance, so they don't share state (if that's what you're getting at).

For serializing, the components themselves don't store their own internal state so we could have a single object at the top for the entire graph if we wanted to. I'm just focusing on the user experience and the API at the moment. I think that is an important part of keeping code maintainable.

It's early days and there's a lot of work I'd like to re-use from both Mercury and virtual-dom, even if they are different approaches to the same idea.