TreeView: Add virtualization support
Added virtualization support to the TreeView component
Closes #5649
How Has This Been Tested?
I ran the demo project and checked that the TreeView worked.
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality not to work as expected)
Checklist:
- [x] The PR is submitted to the correct branch (
masterfor dev,rel-1.xfor maintenance). - [x] My code follows the code style of this project.
- [x] I've added relevant tests.
CLA Assistant Lite bot:
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.
I have read the CLA Document and I hereby sign the CLA
ddjerqq seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You can retrigger this bot by commenting recheck in this Pull Request
DOCS: 1. Why are all the overflow bars visible by default? I'd use a more nicer example, where only the required vertical bar is shown. Also Do you need the outside one also?
Example from DataGrid :
2. By setting Virtualize to true should we not have sane defaults where it would just work? Why are we making our users have to manually set additional settings? In my opinion it should automatically work, but users can further customize it if they want to, changing max height, etc...
3. Can we see more nesting? What will happen? Will it work ok? Will it be a bunch of vertical bars?
EDIT : 3.1 I suspect it might not work correctly not sure? Since Virtualize really likes fixed dimensions...
3.2: I'd like to see the Virtualize working also on the root items.
5. How is dynamic data handled? Imagine I had data to the treeview will it break anything? would be nice to adapt the DEMO version to work with it, since you can already do alot of interactions with the treeview there, and you can check how the Virtualize affects these.
1. Why are all the overflow bars visible by default? I'd use a more nicer example, where only the required vertical bar is shown. Also Do you need the outside one also?
It seems this is the problem of the bigger picture. We pass all the parameters that were assigned to the root treeview elements down to the child tree nodes. I think we should not pass the down, only the necessary that are needed for the child nodes to get the data and states.
1. Why are all the overflow bars visible by default? I'd use a more nicer example, where only the required vertical bar is shown. Also Do you need the outside one also?
It seems this is the problem of the bigger picture. We pass all the parameters that were assigned to the root treeview elements down to the child tree nodes. I think we should not pass the down, only the necessary that are needed for the child nodes to get the data and states.
Probably not sure? Could these be acting as a king of global way of styling all nodes? So if you remove these, some TreeViews that might rely on them, might get a different UI result?
1. Why are all the overflow bars visible by default? I'd use a more nicer example, where only the required vertical bar is shown. Also Do you need the outside one also?
It seems this is the problem of the bigger picture. We pass all the parameters that were assigned to the root treeview elements down to the child tree nodes. I think we should not pass the down, only the necessary that are needed for the child nodes to get the data and states.
Probably not sure? Could these be acting as a king of global way of styling all nodes? So if you remove these, some TreeViews that might rely on them, might get a different UI result?
In this case yes, they act as a semi-global styles. Which is also much different than we do in any other component. We almost never pass styles from the parent down to the child component. The right approach would be to have a callback like GetSomeParameter that we already have for node elements.
I think we should revise all styles on this and only pass the ones that are not going to break the TreeVIew component. Text styling is OK. Overflow and sizing are not OK to be passed.
I have removed styling parameters from not being passed down and tested all examples. And it seems to be working as expected.
@stsrki Already asking for review?
Already gone through all the points? 1, 2,3, 3.1, 3.2, 5?
I will do the 2. point. For others, there should not be any problems.
I will do the 2. point. For others, there should not be any problems.
So you're telling me you don't see any problems with this?
- Can we see more nesting? What will happen? Will it work ok? Will it be a bunch of vertical bars? EDIT : 3.1 I suspect it might not work correctly not sure? Since Virtualize really likes fixed dimensions... 3.2: I'd like to see the Virtualize working also on the root items.
So you're telling me you don't see any problems with this?
- Can we see more nesting? What will happen? Will it work ok? Will it be a bunch of vertical bars? EDIT : 3.1 I suspect it might not work correctly not sure? Since Virtualize really likes fixed dimensions... 3.2: I'd like to see the Virtualize working also on the root items.
It works on all levels. Root level is the one where height and overflow is defined. I tested it on multiple levels, and it works as it should.
I still get an horizontal scroll bar which I don't think it's needed.
The vertical bar shows even though there's nothing to scroll yet, I think there's a setting to make it show only there's scrollable content. (I think it's auto, but I don't remember)
Also if I disable virtualize the TreeView does not go back to the original styling.
I am getting a huge list, can you take a look?
I'll commit my demo code
PS: Use the AddNode button to increase the nodes
I am getting a huge list, can you take a look?
I'll commit my demo code
PS: Use the AddNode button to increase the nodes
I have fixed it. The problem was that we generated TreeViewNodeState each time from the original list. So, in turn, the Key would also be new, making the duplicate between renderings. I've added a simple check for reference on the .Node itself.
@David-Moreira please re-review.

