Tips for partial rendering or caching for many nodes and components

[jmstacey]

Looking for performance tips and suggestions on component caching and efficiently interacting with the vdom/dom for a hobby I'm tinkering with.

I have a large tree of several thousand nodes I'm rendering to a nested ordered list on the page from a hash. Traversing the hash from the store only takes a few milliseconds in benchmarks, but the number of div, ol, and li vnodes created/destroyed during a render! increases the time to several hundred milliseconds before the tree is painted to the screen.

A render rate of 4 frames per second is too slow when the user is interacting with the elements--in this case dragging and dropping those elements. I'm essentially using the Draggable concern from the Web Audio Playground sample where render! is called on every mouse move.

I render a ghost of the item being dragged as well as valid drop targets in divs outside the tree with absolution positioning--i.e. the input from the store to generate the big tree does not change or need to be rendered again.

Some solutions come to mind:

• Internal or self-memoization from the component tree root perhaps
• Conditional or partial component rendering directives or flags
• Lazy rendering--some kind of viewport buffer to only render what the user can see and not what's off screen.

...something better? Suggestions or tips on better ways to do this?

[jmstacey]

To speed up rendering in my case I added a should_render? lifecycle call to the component render in PR https://github.com/inesita-rb/inesita/pull/35 Basically, if should_render? is defined and returns false then the existing virtual node objects will be reused rather than creating new objects which is slow.

[fazibear]

It can be done with separate gem, as described in https://github.com/inesita-rb/inesita/pull/35.