Skip to content

Explore the possibility of rendering large tree data #4115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
matuzalemsteles opened this issue Jun 7, 2021 · 5 comments · Fixed by #4407
Closed

Explore the possibility of rendering large tree data #4115

matuzalemsteles opened this issue Jun 7, 2021 · 5 comments · Fixed by #4407
Assignees
Labels
3.x comp: clay-components Issues related to Clay components. (e.g ClayCard, ClayLabel...) research An issue equivalent to Spike on Jira

Comments

@matuzalemsteles
Copy link
Member

Well, this is an extension for us to be able to create the TreeView component #4111 and it's also part of the collection search #4112 but deeper into the subject of optimally rendering large data in a tree, the TreeView is one of the components that needs it the most, the documentation specification doesn't deal with this issue but we should cover this from the component side, see the ongoing analysis that Daniel is working on from the TreeView.

A crucial part of rendering collections is being able to handle renderings of large amounts of data, depending on the use case, we can work with some strategies like infinite scrolling, virtualization... they are common but for tree, they are more complicated to apply, we can apply load on-demand to subtrees but we will have problems as more items are rendered and a mix of virtualization with load on demand even in memory can be a viable solution but virtualization imposes a lot of rules for this to work as a flat list. So we can study ways how to get this on a tree.

Depending on which solution we follow there is a high possibility of influencing the final component design, so we should be careful to try to align ourselves with #4112.

Goal

  • Rendering strategies
  • Solution
  • Drawbacks
  • Alternatives
@matuzalemsteles matuzalemsteles added comp: clay-components Issues related to Clay components. (e.g ClayCard, ClayLabel...) 3.x research An issue equivalent to Spike on Jira labels Jun 7, 2021
@matuzalemsteles
Copy link
Member Author

Well, @julien had done some initial research on this and he found a lib https://github.com/Lodin/react-vtree that handles virtualizing a tree, ideally, we don't want to add a dependency to a component but it might help us understand how to get there on list virtualization for a tree.

I'll keep that still open to exploring after we get more insights from #4117, maybe working on the #4117 issue first can help better understand how the API will develop.

@julien
Copy link
Contributor

julien commented Oct 20, 2021

@matuzalemsteles seems this was fixed with this pull request right?
If that's the case, I'd close this issue, if it's not the case, just ignore this comment.

@matuzalemsteles
Copy link
Member Author

hey @julien, I ended up forgetting to answer. I'm still keeping this issue to add some more load test cases to cover the different scenarios TreeView can expect in DXP and also to see if we really should consider virtualization here.

@julien
Copy link
Contributor

julien commented Oct 25, 2021

@matuzalemsteles of course. I think @beltranrengifo and @claraizquierdo have interesting use cases.

@github-actions
Copy link

This issue has been merged and will be released in DXP at https://issues.liferay.com/browse/LPS-133328

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.x comp: clay-components Issues related to Clay components. (e.g ClayCard, ClayLabel...) research An issue equivalent to Spike on Jira
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants