Optimizing mounting to a serverside rendered HTML tree (DOM hydration)

[dineshselvantdm-zz]

Right now Mithril recalculates the VDOM while mounting over a server-side rendered HTML. Can it be optimized?

[pygy]

It is called DOM hydration, and it would need explicit support.

I was looking into it last autumn before being side tracked by the router.

[dead-claudia]

I also looked into it some in 0.2.x, and it's non-trivial to do in general. You literally have to build the initial tree differently, and it will inevitably run into complications with m.trust. You also have the secondary concern of whether the tree is even correct compared to the vnodes.

[ChrisGitIt]

Hi everybody,

i currently worked on a "hydration" feature for mithril. RIght now its properly working for me. There are just minor changes to mithril.js to make it work (mainly its passing my hydration function to "rendering" mithril methods. So for example
m.route(document.body, '/', json_routes)
... becomes ...
m.route(document.body, '/', json_routes, hydration_func)

I just experienced some smaller issues that i think are "unresolvable". For example, if your "create" a several following text nodes, it will ran into a hydration problem.

For example:
m('div', [ $val1 ? 'OK': '', $val2 ? 'OK': '', ])
=> theses renderings are problematic.

I thinks this is primarily the same issue as with using m.trust ... but as i write this ... i just realize that while having control about the server side rendering (https://github.com/StephanHoyer/mithril-isomorphic-example), it might be possible to enclose all subsequently following text nodes with a tag and this way having the possibility to fully rehydrate the dom on the client side.

Is anybody interested in my early alpha "rehydration" approach? My approach is a single function, currently 8 KB unzipped, commented, beautified. I might publish it, so my approach itself might be verified and extended.

Greats,

Chris

[dead-claudia]

@ChrisGitIt

I just experienced some smaller issues that i think are "unresolvable". For example, if your "create" a several following text nodes, it will ran into a hydration problem.

Try either joining Mithril text nodes where possible or just diffing the nodes without the backing components - that will resolve the diff.

Note that Mithril is missing a hook that would otherwise allow third-party integration with this: the ability to mount a root + component without rendering first. @pygy @tivac Would you all support such an addition, something like m.mount(root, component, {hydrated: true})?

[ChrisGitIt]

Hi isiahmeadows and thanks for your feedback!

Joining text nodes is very difficult. A component can return a text node, arrays can return text nodes ... to make my hydration function work, it needs two runs. The first run would be the thing that you described ({hydrated: true}), the second would be to actually assign the vnode.dom ... this actually was my first approach, and somehow i started all over ... i think i saw the opportunity to do it in one run and keep my code size small.

I would much prefer my solution right now despite the fact that two text nodes can occur ... i just have to be a little carefull writing my components and m() markup.

I think the {hydrated: true} will result in a much bigger mithril code base ... i mean like 1 or 2 more KB's, not much actually, but everybody who does not want hydration has to load 2 more KBs.

Passing a vnode accepting function as third argument is a perfect fit. It requires marginal change to mithril code base (just three functions need adjustment about the third parameter) and if you need hydration, you load and pass in the hydration function ...

Am i on the wrong track? Feedback appreciate!

[dead-claudia]

@ChrisGitIt

Joining text nodes is very difficult. A component can return a text node, arrays can return text nodes ... to make my hydration function work, it needs two runs. The first run would be the thing that you described ({hydrated: true}), the second would be to actually assign the vnode.dom ... this actually was my first approach, and somehow i started all over ... i think i saw the opportunity to do it in one run and keep my code size small.

Note the alternate (diffing the text nodes) would be much easier to do, at the cost of recreating text slices.

I think the {hydrated: true} will result in a much bigger mithril code base ... i mean like 1 or 2 more KB's, not much actually, but everybody who does not want hydration has to load 2 more KBs.

To clarify, that option would literally be just to skip this line, to enable third-party support (we've done similar in other areas to help mithril-node-render and a few others out).

[ChrisGitIt]

Hi isiahmeadows and thanks for your feedback!

I thought about your infos and i think it will unnecessarily add code to the mithril base.

Right now, it looks like all render/render.js
-> createText
-> createComponent
etc. have to be rewritten to appreciate {hydrate:true}

My current soultion just needs marginal changes to mithril:
/render/render.js
function render(dom, vnodes) { ... if (dom.vnodes == null) dom.textContent = ""
becomes

function render(dom, vnodes, hydrate) { ... hydrate(dom, vnodes, hooks, null);

/api/mount.js
=> replace two
redrawService.render(root, *)

with
redrawService.render(root, *, hydrate)

About the diffing text nodes: I'm currently experimenting with this. I think its possible to to properly hydrate text nodes. Its not actually joining the text nodes but to create extra text nodes and remove just the one that needs to be hydrated ... this might lead to a flicker ... i'm not totally convinced with this solution... there also might be a solution by using streams ... well, haven't dived much into them.

Any feedback appreciate!

Greats,

Chris

[leeoniya]

what reservations do you guys have against joining adjacent textnodes? i have not seen any issues with doing so, and it makes hydration pretty trivial [1].

[1] https://github.com/leeoniya/domvm/blob/2.x-dev/src/view/addons/attach.js

[ChrisGitIt]

Hi leeoniya!

And also thanks for your feedback! I just had a quick look at your provided trivial solution.

But i think the problem remains ... i think i have to recapitulate for myself:

If there is a call like m('div, ['A','B=',m(my_component)])) and
var my_component = { view: function() { return Math.random() } }
is given, the rendered root DOM Element would look like this=>

AB=0.23

When dom hydration takes place, m() call from before gives me a vnode like this
{ children: ['A', 'B=', my_component] tag: 'div' }
and my root DOM Element "Node View(!!)" would look like this
{ nodeType: 1 nodeName: 'div' children: [{nodeType: 3, nodeValue: 'AB=0.23'}] }
SOOOO ... i'm not sure if this leads to anywhere ...

When i hydrate through the VNODE, the vnode children will ALL be applied to the same DOM text node ... AND ... when there is a redraw, only the my_component would change ... and the change will directly applied to the vnode.dom attached dom node ... and this dom node is the text node with the content "AB=0.23" SOOOOO --- yeah, i think my thought were right --- > the updated vnode.dom.content would be 0.83 and not the expected AB=0.83.

OK, i'm done. I think this is a very simplified problem description, but the problems that arise while doing something like this are very tricky to track down and messes up the whole redraw cycle.

So my current work in progress solution is to create new text element WHILE hydrating, remove the suspicious "joined" DOM text node and append three dom text nodes childs to the DOM div node.

Any feedback appreciate! I'm also not sure if the problem might be easily resolved within the mithril core. Also not sure if the problem described is actually a problem. During developing my hydration function, it looks like this is a problem ... haven't tested it lately ...this might ruin several days of thinking and testing about resolving the problem ... but @isiahmeadows might have had the same problems ... so i'm confident, this IS a problem ;-)

Greats,

Chris

[pygy]

Alternatively, while hydrating, if you encounter several consecutive text vnodes, you can turn them into a fragment of textNodes and replace the textNode in the DOM with it.

Empty text vnodes between elements will also need special care.

Edit: Specifically:

m('p', '')
m('p', '', m('p'))
m('p', m('p'), '')
m('p', m('p'), '', m('p'))
m('p', m('p'), '', '', m('p'))

[dead-claudia]

@leeoniya I'm accounting for the case of fragments. Here's a contrived example of where joining text nodes would end up not matching Mithril's internal model, and Mithril doesn't currently have a layer between text nodes and its model of their slices.

const A = {
    oncreate({dom}) { /* vnode.dom is the text node's dom */ },
    view() { return ["foo"] },
}

const B = {
    view() { return [m(A), "bar"] },
}

[leeoniya]

you may be interested in @thysultan's feedback starting here:

domvm/domvm#101 (comment)

i don't know if the latest dio still works this way.