Thanks for your reply.
Honestly, it depends on particular data and how a user wants to focus on data.
For example, if we are looking at the list of employees grouped by departments, with pagination showing ten results per page; the most expected behavior is to see the number of pages based on the number of departments (groups), and correspondingly pager info to say "1-10 of 100 departments". That way, the department, when opened, will always show all underlying employees, and never spread across into multiple pages.
However, I can imagine that users might be interested in employee data as much, so we can potentially spread the departments into a couple of pages if needed and base our page number on the number of employees. So, then pager info will say 1-10 of 2000 employees. However, if we need to continue showing employees from the department that started on the previous page, we still have a department tree item on the page to collapse it. Currently, if you have ten items per page and you expanded the parent item on page 1 and went to page 2 to see the child items, you will need to return to the page 1 to collapse the parent.
For the cases above, the main two differences from current tree list behavior are:
- we do not change the number of pages or totals based on tree expanded items
- we do show top group element on every page, to give a context and to allow a user to collapse the parent
I hope this makes some sense :)
For now, I was able to get what I need by controlling the Pager component separately and making TreeList not pageable.