[RichTreeViewPro] Add virtualization

[flaviendelangle]

Closes #9685

• Proof of concept: https://deploy-preview-13520--material-ui-x.netlify.app/x/react-tree-view/rich-tree-view/items/#virtualization

Extracted PRs

• [internals] Move utils needed for tree view virtualization to shared package #14202
• [TreeView] Rework how items are being rendered in Rich Tree View components #14749

Benchmarks

• https://github.com/ChilliCream/react-aspen

TODO

Very incomplete list

• Make sure it reacts correctly to collapsing / expanding
• Make sure it react correctly when items change
• Fix the width of the content to never have a horizontal scrollbar
• Implement the smart buffer of the grid (pre-load more items in the direction being scrolled)
• Do not unmount any "active" item (the item being editing, the focus item, the item being dragged, ...)

[mui-bot]

Deploy preview: https://deploy-preview-13520--material-ui-x.netlify.app/

Updated pages:

• docs/data/tree-view/rich-tree-view/items/items.md

Generated by 🚫 dangerJS against 6640b09

[JCQuintas]

I spent some time looking at the PR and I see what you meant now. 😆

I don't know if it is possible to do full virtualization on a nested DOM arch. And if possible it would still be much more complex than just having flat DOM... 🙃

With that said.

If we can assume all items have the same height, and we know the list of items beforehand, however nested it is, we can try to flatten the list keeping references, eg:

const items = [
  {
    id: '1',
    children: [{ id: 'a' }, { id: 'b', children: [{ id: 'I' }] }],
  },
  {
    id: '2',
    children: [{ id: 'a', children: [{ id: 'I' }, { id: 'II' }] }, { id: 'b' }],
  },
];

// Maybe use the array index if we don't have ids? (e.g. `'0.0.0, '0.1.0'`)?
const flatIds = ['1', '1.a', '1.b', '1.b.I', '2', '2.a', '2.a.I', '2.a.II', '2.b'];

We could then have a custom render that knows this context, so if say, we are inside 2.a.II, it keeps 2 and 2.a rendered, albeit slightly offscreen, and scrolls the elements inside 2.a

| 2.         |
|| a.       ||
||| ...n-m ||| <- "fake" scroll happens in `a.` content
---visible----
||| ...n   |||
---visible----
||| ...n+m |||

Though I'm not sure it would work, and orchestrating all these containers might be a real pain, because we will have depth+1 containers on the screen at all times 😅

[flaviendelangle]

@JCQuintas I think we have the same idea 👌

If we can assume all items have the same height, and we know the list of items beforehand, however nested it is, we can try to flatten the list keeping references, eg:

At some point I have to work on a flat list yes, even if the final DOM structure end up being nested.
Right now, I have the flat list of elements to render, with some work I could turn it back into a tree and make sure to keep any ancestor that have some children rendered.

But then the main challenge is to orchestrate all those offsets correctly 😬 , hopefully it's doable without to much headache...

---

Keeping the depth+1 contains on the screen at all time is not a big issue IMHO (except on very specific edge cases), we could even not render the content of those ancestors but just the groupTransition if it improves the performances (and adapt the offsets of course).

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[flaviendelangle]

Performance-wise, it looks like trying to virtualize with a Collapse is not the best idea, a lot of the computing time is spent in this component (and right now the transition doesn't even work).

I'll explore a bit to see if we can correctly support Collapse + virtualization or if we should remove the transition when virtualization is enabled.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.