Pagination on TreeList

Hello, Vitaliy,

The TreeList paging requires all records to be passed to the TreeList and the paging is done only client-side internally by the component.

I agree that paging on the TreeList can be confusing some times, but this is due to the unpredictable results when expanding or collapsing items.

For example, what is the more user-friendly result that is expected given the same data?

Regards,
Stefan
Progress Telerik

Hi Stefan,
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.
Thanks,
Vitaliy.

Hello, Vitaliy,

Thank you for the very detailed information.

Indeed, using a separate Pager is a great option for this case.

Making this built-in has its limitations, as the behavior depends on external factors, and if we make it to cover 1 use case, it will be strange for others. This is why we try to made in to show the pages based on the expanded and visible items directly instead of making assumptions what the user will expect, as this could produce unexpected results for different user groups.

Regards,
Stefan
Progress Telerik