Primeng: Primeng-5.2.0-rc.2 issue with paginator when using row grouping

Created on 23 Jan 2018  路  7Comments  路  Source: primefaces/primeng

There is no guarantee in receiving an immediate response in GitHub Issue Tracker, If you'd like to secure our response, you may consider PrimeNG PRO Support where support is provided within 4 business hours

I'm submitting a ... (check one with "x")

[X] bug report => Search github for a similar issue or PR before submitting
[ ] feature request => Please check if request is not on the roadmap already https://github.com/primefaces/primeng/wiki/Roadmap
[ ] support request => Please do not submit support request here, instead see http://forum.primefaces.org/viewforum.php?f=35

Plunkr Case (Bug Reports)
Please fork the plunkr below and create a case demonstrating your bug report. Issues without a plunkr have much less possibility to be reviewed.
I created a GITHUB repo for this: https://github.com/loicsalou/prime-ng-issue.git

Current behavior
I implemented a very simple table showing 16 cars indexed from 0 to 15 (3 brands BMW Fiat and Renault having respectively 7, 3 and 6 models). Cars are sorted by brand name by "turbo" p-table.
Opening the app, table is not grouped, simply trigger grouping by checking the checkbox on top of it.
Based on Primeng showcase demo with grouping I implemented my own vision of grouping, with collapsible rows. I get 3 groups BMW (7 models), Fiat (3 models) and Renault (6 models). Groups can be expanded or collapsed.
When grouping you can see everything works fine when you have 20 rows per page, 3 groups with expected models in each.
Now the issue, diminish the number of rows per page:

  • when 15 you get the 3 groups and row 15 is on the second page ==> correct
  • when 10 you get 2 groups, collapsed This means 2 ==> wrong. The page can show 10 rows, I expected the 3 collapsed groups.
  • expand the 2 groups on the first page. You get car from index 0 to 10 + 2 headers. I expected 10 but it's OK for me (headers added).
  • blocking issue: page 2 is empty ! my third brand has vanished.
  • I go on testing... changing number of rows per page to 5 it's even worse. I get only 1 row, a group header actually, which shows 5 cars when I expand it. Page 2 now contains the 2 remaining models of the same brand BMW... plus 3 Fiat ! no header group for Fiat ?
  • still going on, page 3 and 4 are empty. Brand Renault vanished.

If you uncheck the "group by brand" checkbox, grouping is removed and cars are actually there. Inside the code I checked my groups are correct. They are.

Expected behavior
I expect table to be paginated by number of actually displayed in a page, not the rows of data. I also expect the table not to lose my data after the first page.

Minimal reproduction of the problem with instructions
checkout provided repo, install and ng serve, then try the scenario I described above.

What is the motivation / use case for changing the behavior?
tree-like feature is essential in my business functionalities. They allow consolidated view of the data and an easy drill down. I need to gather on a single page the groups so the user can drill down in each group according his needs. Prime's TreeTable is not flexible enough, I need to choose and move columns, resize them, sort inside groups and so on and so forth.

Please tell us about your environment:
both Windows7 and MacOs

  • Angular version: 5.2.1 - all libs most recent version

  • PrimeNG version: 5.2.0-rc.2

  • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
    Chrome and Safari

  • Language: [all | TypeScript X.X | ES6/7 | ES5]
    Typescript

  • Node (for AoT issues): node --version =
    I did not check AOT

Most helpful comment

I got it working.
Issue was coming from a misunderstanding on my side.
rowIndex we get when using let-rowIndex is the index of the row _in the current page of the table_.
In order to handle correctly the grouping we must calculate the actual index of the row we are creating, which is actually = to first+rowIndex, first is given by onPage event from the table.

I can now handle this and I'm really happy ! ;-)
I update my repo so that anyone is able to see the issue and see how the fix works.
2 branches "bugfix/showing-issue" and "bugfix/solution"

All 7 comments

I got it working.
Issue was coming from a misunderstanding on my side.
rowIndex we get when using let-rowIndex is the index of the row _in the current page of the table_.
In order to handle correctly the grouping we must calculate the actual index of the row we are creating, which is actually = to first+rowIndex, first is given by onPage event from the table.

I can now handle this and I'm really happy ! ;-)
I update my repo so that anyone is able to see the issue and see how the fix works.
2 branches "bugfix/showing-issue" and "bugfix/solution"

@loicsalou I couldn't find above mentioned branches.
I am facing the same and looking for a solution. If you can help me with this that will be great.

@loicsalou The repo does not exist anymore, can you provide an example please? I'm facing the same problem with empty pages even when groups are collapsed.

I have the same issue... and I don麓t have solution!

I have the same problem you described. But I did not find the solution in your project. I would love to be able to re-attach your solution.
My case:
I have a grouped table and I also need to have 10 rows per page.
The problem is that if I make pages it doesn't work well maybe because it computes the grouped lines
Thanks and waiting for an answer

I have the same problem you described. But I did not find the solution in your project. I would love to be able to re-attach your solution.
My case:
I have a grouped table and I also need to have 10 rows per page.
The problem is that if I make pages it doesn't work well maybe because it computes the grouped lines
Thanks and waiting for an answer

I got it working.
Issue was coming from a misunderstanding on my side.
rowIndex we get when using let-rowIndex is the index of the row _in the current page of the table_.
In order to handle correctly the grouping we must calculate the actual index of the row we are creating, which is actually = to first+rowIndex, first is given by onPage event from the table.

I can now handle this and I'm really happy ! ;-)
I update my repo so that anyone is able to see the issue and see how the fix works.
2 branches "bugfix/showing-issue" and "bugfix/solution"

Is this branch available ?

I fixed it by updating the updateRowGroupMetadata method with an 'actualRowIndex' as follows:

// event: LazyLoadEvent
// pageSize = event.rows;
// page = ((event.first + event.rows) / event.rows) - 1;

updateRowGroupMetaData(entities: any[], page: number, pageSize: number) {
    this.rowGroupMetadata = {};
    if (this.withRowGrouping && entities) {
      for (let i = 0; i < entities.length; i++) {
        const rowData = entities[i];
        const groupProperty = rowData[this.groupField];

        const actualRowIndex: number = i + (page * pageSize);
        if (i === 0) {
          this.rowGroupMetadata[groupProperty] = {index: actualRowIndex, size: 1};
        } else {
          const previousRowData = entities[i - 1];
          const previousGroupProperty = previousRowData[this.groupField];
          if (groupProperty === previousGroupProperty) {
            this.rowGroupMetadata[groupProperty].size++;
          } else {
            this.rowGroupMetadata[groupProperty] = {index: actualRowIndex, size: 1};
          }
        }
      }
    }
  }
Was this page helpful?
0 / 5 - 0 ratings