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.