Only render visible nodes

[tp]

While this is a simple example, I think a real world tree view has quite different requirements to be able to handle a big hierarchy.

For example instead of the nested TreeViews an therefore divs, I would recommend flattening the output.

Would you be interested to discuss and implement this, or do you want to keep this as straightforward as it is?

[chenglou]

What you mean by flattening the output?

[tp]

Currently there are tree-view divs nested inside tree-view divs, which is a straightforward implementation of the mental model.

What I have seen in another tree-view implementation is that performance for huge trees can be greatly improved by flattening the output, like this example:

<ul>
  <li class="indentation-0">Employees</li>
  <li class="indentation-1">Paul</li>
  <li class="indentation-1">Sarah</li>
</ul>

And nodes would be styled (primarily indented) by their indentation class.

This would preferably be combined with only drawing on-screen elements, which should be possible with such a flat structure.

[chenglou]

That's interesting, but wouldn't that require you to define one class per indentation?

[tp]

Well, in practice the styling should probably use inline styles like margin-left instead of global classes to account for infinitely deep nested trees.

[greeze]

@tp We're looking to flatten out our tree structure as well. Do you have any examples of other treeview implementations (preferably React-based) that transform nested data into flat structures? We're running into some performance issues with trees that are nested extremely deeply.

[sunjay]

I did this in my pull request here: https://github.com/chenglou/react-treeview/pull/29

[chenglou]

PR merged!

[tp]

Hi @chenglou,

Reviewing the changes made in the #29 PR, I think I did not communicate my intention clearly here.

What I meant was not rendering node that were off screen (i.e. invisible because they're outside the viewport), not just collapsed.

Depending on the use-case, #29 would there also not help with #34 if thousands of those songs are in a single, expanded node.

[chenglou]

Ah I see. Well, this is certainly trickier and a huge rabbit hole for any list-based infinite scrolling solution. I'm afraid I don't have the bandwidth to implement & maintain such thing, especially specifically for the tree-view, sorry... Feel free to fork this repo though!