Diff-based reconciliation on Rerender

[hexops]

Diff-based reconciliation on Rerender

[pdf]

Thank you very much for the detailed response, I missed the delegation to restoreHTML, and reassignment of the Node, makes all the difference!

[slimsag]

@pdf Vecty already supports reconciliation exactly the same way React does. For an example of this see the TodoMVC example: https://github.com/gopherjs/vecty/blob/master/examples/todomvc/components/pageview.go#L24-L29

Also see the godoc for the Restorer interface (https://godoc.org/github.com/gopherjs/vecty#Restorer) that should be implemented by your component in order to handle restoration (reconciliation).

I think this is just a case of missing docs, so closing in favor of #31 -- please reopen/comment if you feel otherwise :)

[pdf]

@slimsag did you have a read of the linked article? That should explain what I'm talking about here.

As an aside, I was aware of the Restorer interface, but that's not the same thing. On that topic though, I'm not sure calling the function Restore is ideal, and the return bool is lexically backwards - Restore -> true actually means don't restore the element, pretty confusing.

[slimsag]

@pdf Sorry for the confusion. I did misread your original post.

However, the Restorer interface is used internally by Vecty already in order to restore *HTML structs by calculating the difference between the previous render and applying the modifications (instead of creating new elements) just as described in the React reconcilliation document you linked (https://facebook.github.io/react/docs/reconciliation.html).

The relevant code is here: https://github.com/gopherjs/vecty/blob/master/dom.go#L98-L193

The one case where we don't currently do well, however, is with reusing list elements, and that is issue #25

[pdf]

So, doRestore applies from the old node to the new node, then the new node replaces the old node in the dom in most instances? Do I have the right reading of the code here?

If so, isn't that the opposite of what should happen, which is that the new render is generated, then applied onto the old node when of a compatible type, to avoid tearing down the whole tree for every update?

[slimsag]

So, doRestore applies from the old node to the new node, then the new node replaces the old node in the dom in most instances? Do I have the right reading of the code here?

lol that is obviously not what it does I hope :P that would defeat the entire purpose of doing things like this, as you already said. The correct reading of the code would be something like:

1. vecty.Rerender invokes doRestore with the component's previous Component.Render and the new Component.Render as parameters.
2. doRestore effectively just invokes (*HTML).Restore
3. (*HTML).Restore makes one of two decisions:
   • Can we reuse (read: just modify) the old browser DOM element to match the new render? If so it delegates to (*HTML).restoreHTML
   • Do we need to create the browser DOM element from scratch (i.e. is the previous render nil/non-existent)? It creates the real DOM element if so.
4. (*HTML).restoreHTMLs goal is to restore or reinstate the friendly relationship between the new render (the h method receiver) and the previous/old render (the prev method parameter):
   1. It begins by immediately using the same browser HTML node instead of creating a new one.
   2. It then determines what properties have been modified, and sets those on the existing browser DOM node
   3. It removes any properties from the node that existed in the old render but not the new one
   4. It does steps 2 & 3 above for attributes, then styles, event listeners (oversimplification), and unsafe HTML if present.
5. It then proceeds to do the same thing for all of that component (the *HTML)s children, recursively (oversimplification)

There's more here to cover, like my oversimplification of event listener management and child component recursion, but the point is this:

Yes, Vecty will always reuse the same DOM element in all cases except:

1. If the render was a list of elements and they are no longer in the same order, for this we would need 'keys' like React has. See issue #25
2. If the actual browser DOM element tag has changed, e.g. if what you previously rendered was a div and what you've rendered now is a p then Vecty (and React) must destroy the div and create a new p.

Does this all belong in some documentation? You bet it does! And it will be soon :)