Grid group that spans multiple pages

[drew]

I don't particularly like how the grid grouping is working, and I'm hoping that I'm just configuring it incorrectly. My use case is for a grid that contains a lot of data (1000s of rows) to allow grouping of columns by dragging to the groups area. I'd like to have client-side paging enabled because there is a lot of data.

The behavior of the grid is strange to me though, because I can only see the groups that apply to the rows currently visible on the page. So if my page size is 20 and my first group has 25 items in it, then I'll just see the one group, even if I minimize it.

Here are a couple of things that I'd expect to happen instead:

• Some indicator that explains that there are more items that apply to this group on the next page
• When viewing the next page, some indicator that explains that there are previous items in the same group
• Upon minimizing the group, I'd expect to see the second group on the first page of results, with its items now visible

Here's a jsfiddle that shows the behavior that I'm currently seeing: http://jsbin.com/joleriva/1/edit
Notice how you see 4 items in the "Foo: 1" group, and if you go to the second page you see one additional item that belongs to that group. If (on the first page) you minimize "Foo: 1" group you don't see anything but the group header and the paging controls.

Like I said, I really hope that I'm just missing some configuration options that will make this work in a more intuitive way.

By the way, I've looked into the Virtual Scrolling with groups, but that has problems of it's own when you minimize a group... http://trykendoui.telerik.com/ivum

[Dimo]

Hello Drew,

Generally, paging occurs before grouping, otherwise the whole datasource should be grouped, which would greatly reduce the performance. As a result, the Grid doesn't know whether there are items from the displayed groups on other pages. In addition, showing items from subsequent groups when you collapse a group would mean that the page size should be changed on the fly, which cannot happen either.

Regards,
Dimo
Telerik

 

 

[drew]

Thanks for the response, Dimo. I don't disagree that there are some performance implications of grouping an entire datasource, but I'd suggest that it's the responsibility of the consumer to address that. For example, by disallowing grouping when a certain threshold for number of records has been broken. Again though, I think that's a decision for the developer that's implementing the grid, not the grid vendor. The very nature of grouping means that the entire datasource has to be parsed into smaller subsets.

As for the changing page size, I guess I don't agree that the page size would need to change. This wouldn't be a problem if the header row were counted towards the page size. So, if you have a page size of 10 and the first group has 15 items, then the first page would show the header row with 9 data rows pertaining to it. The next page would show the remaining 6 data items, plus whatever group falls after it. In that scenario, if you minimized all groups then you'd see 10 groups per page.

A likely easier solution might just be to take advantage of something like the grid hierarchy to handle grouping.. breaking the datasource into multiple different grids nested beneath the header they pertain to. Something like this demo where the main grid has only one column, for the selected grouping field: http://demos.telerik.com/kendo-ui/grid/hierarchy

For what it's worth, the vast majority of grid vendors have implemented grouping exactly the way that you have. I've found one that does mostly what I expect it to do when grouping (jsfiddle), but the rest of their suite beyond the datagrid feels quite half-baked. Unfortunately, great grouping seems to be very important to my business users. I'd love to use KendoUI, but it's going to be a very difficult sell with this one concern as it is.

[Dimo]

Hello Drew,

I understand your point of view and requirements, but I also need to be honest that we do not support the desired behavior at this point and will probably not support it in the future. Sorry about that. You have correctly observed that most vendors have implemented grouping in the same way as we have.

Nevertheless, I hope that you will still appreciate what Kendo UI provides, compared to other vendors' offerings.

Regards,
Dimo
Telerik

 

 

[Andy]

Drew, did you eventually chose a grid that works the way you want with grouping, paging and large datasets. We have the same issue with Kendo UI's grid, and have from your post looked into the dx-grid which handles this scenario. Did you end up with that, or something else? Thanks in advance.

[Ning]

Hi Dimo,

That's not true. For example, AngularJS UI Grid can handle 10000+ rows with pagination and good performance. When you group by one column, all the groupings are collapsed to fill up the first page and the continuous pages if the number of groupings are more than the page size. So user has a good view of all the groupings. But in Kendo UI Grid, like Drew's problem, if I have two groups of data and the first group has data more than the page size, then I can only see one group on my current/first page, which is not ideal because user would think there's only one group. They will only see the other group when they navigate to the next page. No other grid does grouping this way. I have never seen any behaviour like this. Pagination should happen last, no matter if it's filtering or grouping. So is there a way for kendo ui grid to group/filter before paging? Without paging, the grid is unuseable with a large data se like 10000+ rows even with serverPaging, serverGrouping, serverFiltering, virtual scrolling enabled. In fact, serverPaging and serverGrouping perform much worse than client side paging and grouping. 

[Dimo]

Hello Ning,

Thank you sharing your opinion.

We refrain from discussing competitor products in our forums, but I can confirm that most of the direct competitors of the Kendo UI Grid have implemented grouping and paging in the same way as we have. I am not saying that this is the best possible option for users, or the only possible way, but is what we have opted to do after evaluating the pros and cons.

Regards,
Dimo
Telerik by Progress

[Pradeep]

Hello Dimo,

   Is still this issue solve?, I am also facing this issue if there any workaround? 

[Dimo]

Hello Pradeep,

I confirm the following still applies:

Generally, paging occurs before grouping, otherwise the whole datasource should be grouped, which would greatly reduce the performance. As a result, the Grid doesn't know whether there are items from the displayed groups on other pages. In addition, showing items from subsequent groups when you collapse a group would mean that the page size should be changed on the fly, which cannot happen either.

I understand your point of view and requirements, but I also need to be honest that we do not support the desired behavior at this point and will probably not support it in the future.

Regards,
Dimo
Progress Telerik

[Udvikler]

Hi Dimo,

 

Any update about it?

Any workaround?

[Viktor Tachev]

Hi Udvikler,

 

The description provided by Dimo is still valid. When a group in the Grid is collapsed that hides the rows from that group. Showing another group would mean that the page size should be changed on the fly. Furthermore such behavior would not work as expected when server operations are enabled because a request will be sent to the server when a group is collapsed.

 

Regards,
Viktor Tachev
Progress Telerik