New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Matt-Esch/virtual-dom #10

Closed
alexmingoia opened this Issue Nov 21, 2014 · 9 comments

Comments

Projects
None yet
4 participants
@alexmingoia

alexmingoia commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@anthonyshort

anthonyshort Nov 21, 2014

Owner

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.

Owner

anthonyshort commented Nov 21, 2014

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 comment has been minimized.

Show comment
Hide comment
@alexmingoia

alexmingoia Nov 21, 2014

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.

alexmingoia commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@anthonyshort

anthonyshort Nov 21, 2014

Owner

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.

Owner

anthonyshort commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Raynos

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Nov 25, 2014

@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.

Raynos commented Nov 25, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@anthonyshort

anthonyshort Nov 25, 2014

Owner

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.

Owner

anthonyshort commented Nov 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Raynos

Raynos Nov 25, 2014

@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.

Raynos commented Nov 25, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@Matt-Esch

Matt-Esch Nov 25, 2014

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.

Matt-Esch commented Nov 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@anthonyshort

anthonyshort Nov 25, 2014

Owner

@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.

Owner

anthonyshort commented Nov 25, 2014

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment