Comparison to Yew wrt updating child state without re-rendering parent's DOM

[Boscop]

Am I correct in assuming that draco doesn't have this issue? DenisKolodin/yew#350

IOW, in draco, is it possible to update a child component's state without causing a re-render of the parent's DOM (only causing a re-render of the child whose state actually changed)?

E.g. if my main app element receives ws msgs at 30 fps and each one should be passed down through many layers of components until it modifies some small child's state at the bottom of the component tree, will only that child's DOM be re-rendered, or all intermediate children's DOM, too? (The children in the chain between app->child->...->child->target-child)

(This issue is a huge pain for me with Yew, I'm considering porting my app to draco if it doesn't have this issue.)

[qthree]

Draco doesn't have components, so every render is full remake of VirtualDOM. And currently every update leads to render (check #8 for optional re-render after update).

[Boscop]

But if self updates a child's state, will it trigger a render of self? Or only of the child?

[utkarshkukreti]

@qthree is right. Every update recreates the whole virtual dom and the whole tree will be diff'd against the previous virtual dom and the changes will be applied to the real dom.

I've spent a lot of time optimizing the virtual dom creation and patching though, so you may want to benchmark rendering the dom at 30 fps and compare that to Yew.

Here are the results of js-framework-benchmark: https://gist.github.com/utkarshkukreti/68faa737a9f975ccb3873b9400c2987b. I haven't submitted the implementation to the official repository yet but the code is in examples/jfb.rs.

[qthree]

@Boscop there is no such thing as 'child's state' in draco: it follows more pure, Elm-ish, architecture. Before, i tried to use percy, another rust web framework. It also doesn't have components, but can render VirtualDOM both on client and server sides. But it doesn't store JsValue refs to html elements, so it's making 2 passes: first is diffing between old and new VirtualDOM to generate patches, and second is to re-visit real DOM to apply patches. And because of that it's approximately 2 times slower than draco. I have big table to render, and when searching over it, with percy freezes between key presses inside search form were apparent, but with draco i can't notice any delays between input and re-render (also compilation speed is pretty good). So you probably shouldn't care much about performance beforehand.