p-table pagination always redirect to page 1 after changing contents when there is a filter applied

[twopelu]

Describe the bug

PrimeNG table (p-table) always redirect to page 1 when the content is updated (manually or reactively) and there is a filter applied. This behavour does not happen when there are no filters applied.

Environment

(see stackblitz)

Reproducer

https://stackblitz.com/edit/p-table-pagination-with-filters-bug

Angular version

11.0.5

PrimeNG version

11.0.0

Build / Runtime

Angular CLI App

Language

TypeScript

Node version (for AoT issues node --version)

(stackblitz)

Browser(s)

(all)

Steps to reproduce the behavior

1. Open the stackblitz: https://stackblitz.com/edit/p-table-pagination-with-filters-bug
2. Filter by word "Seat" in the global filter textbox
3. Click button "Add Vehicle" until there are 4 or 5 pages of Seat cars
4. Navigate to the last page
5. Click button "Add Vehicle"
6. The table is redirected to page 1 (it should remain in current page)

Expected behavior

The table should remain in the current page when changing the model, and only redirect to first page if the page not exists anymore (see related issue https://github.com/primefaces/primeng/issues/9707.

[twopelu]

It also happens with Angular 10 and PrimeNG 9.

[Achiar91]

I have the same issue, after triggering an event on one item in the list, it resets back to first page, how can I make it stay on the page? Thanks

[cetincakiroglu]

Hi,

It's not a bug and it does not reset the records. It filters the records and you're seeing filtered records from the beginning. If you stay on the same page ex: page 3 and if you have just 2 entries after the filter is applied, you'll see the empty page on the 3rd page while all results are listed on the first page.

[twopelu]

It's not a bug and it does not reset the records. It filters the records and you're seeing filtered records from the beginning. If you stay on the same page ex: page 3 and if you have just 2 entries after the filter is applied, you'll see the empty page on the 3rd page while all results are listed on the first page.

@cetincakiroglu excuse me but this is not the case, please give it a try and reproduce it in the StackBlitz.

If you apply a filter, move to the last page, and then add a new record, the table goes to page 1 even the last page exists. If the page did not exist anymore it would be correct, but it does exists.

If you need further explanation just let me know. Thanks in advance!

[twopelu]

Thanks for reopening :-)

Please could you consider this as a defect? This is indeed an unexpected behaviour and makes the table unusable with filters and real-time data, which is a must in modern applications. This is an imporant issue to the final users.

[twopelu]

In any case, do you know if there is any workaround? I'd really appreciate any help.

I have tried setting the page number after updating the model but the table blinks.

[iamade]

I am also experiencing this same issue, after typing out the variable to be searched in the search box. It calls reloads the end point but does not filter the data. below is a screenshot of the lazyload event

[iamade]

Furthermore the code in the stackblitz https://stackblitz.com/edit/primeng-tablelazy-demo?file=README.md Is totally different from what is in the source and github here http://primefaces.org/primeng/table/lazy

This is quite miss leading, please help upload the correct implementation Thank you

[twopelu]

Just to clarify, the issue happens in both lazy and regular tables.

[iamade]

i have not tried it in the regular tables, because the lazy is what i need for a large dataset

[twopelu]

I have created another StackBlitz based on the official docs for pagination and filtering, just to make sure that the problem is reproduced and happens both in implicit and programmatic pagination.

https://stackblitz.com/edit/primeng-tablepage-demo-yn8zcy

https://www.primefaces.org/primeng-v9-lts/#/table/page https://www.primefaces.org/primeng-v9-lts/#/table/filter

[twopelu]

Any workaround? I'm not looking for a fancy solution just something that does the trick. This is a critical issue for our users.

[twopelu]

I think the problem is related with the code in _filter() private method which might be mishandling the current page after model updates in the table: https://github.com/primefaces/primeng/blob/9.1.3/src/app/components/table/table.ts#L1259

[jesuspa17]

News?

[rtv10dev]

Hi, same problem here, any workaround?

[mertsincan]

Hi,

It is by design. But, you can intervene in it by setting up a controlled structure yourself. Exp;

export class TableFilterDemo implements OnInit {
...
    first: number = 0;
    lastFirst: number = 0;

    onFilter() {
        this.first = this.lastFirst;
    }

    onPage(event) {
        this.lastFirst = event.first;
    }
...

<p-table [first]="first" (onFilter)="onFilter()" (onPage)="onPage($event)" [rows]="10" [paginator]="true" ...>

Best Regards,

[twopelu]

I insist that this is a bug, even if it is "by design" clearly it does not behave as expected when you have a table with real time updates.

Users do not expect it to work like this, this is critical for our application which is a real time system and it is causing us trouble with our clients.

Please reopen the issue and consider including a fix in next version. Thanks in advance.

[twopelu]

Hi,

It is by design. But, you can intervene in it by setting up a controlled structure yourself. Exp;

export class TableFilterDemo implements OnInit {
...
    first: number = 0;
    lastFirst: number = 0;

    onFilter() {
        this.first = this.lastFirst;
    }

    onPage(event) {
        this.lastFirst = event.first;
    }
...

<p-table [first]="first" (onFilter)="onFilter()" (onPage)="onPage($event)" [rows]="10" [paginator]="true" ...>

Best Regards,

Thanks for the workaround, but I would rather keep paging managed by PrimeNG and not programmaticaly, as this causes another bunch of problems. I think this should be fixed.

[Steenr99]

I think the problem is broader than what is described above. The problem described above is in the scenario when you have an active filter. (in the sample a global filter)

The reset to the first page also occurs the moment you have a column filter 'present' (not filled in). In that scenario adding an new entry --> jump back to first page.

If the following p-columnfilter is added In the stackblitz of twopelu :

      <th *ngFor="let col of columns" [pSortableColumn]="col.field">
        {{ col.header }}
        <p-columnFilter
          type="text"
          [field]="col.field"
          display="menu"
          class="ml-auto">
        </p-columnFilter>
      </th>

Clicking on the add button result in jumping back to the first page.

[ThorstenKunz]

So with the workaround I get an Expression has changed after it was checked. exception thrown in development mode and it only works once. Means when you are on page 5 and edit one entry it will stay on 5 but when you then edit a second row it jumps back to page 1 again. So doesn't really seem to be a viable workaround. This is PrimeNG 13.4.1, not sure if that workaround works any better with newer versions. But if this is how it was designed then I'd like to challange that design decision. If virtually all of my users over here are so irritated about this behaviour that I get bug tickets opened about this over and over I really don't think that this is how the UX should be to begin with. While that might just be my users I just don't think that anybody would expect to get thrown back to page 1 when you edit a record on page 5. And for the resoning given that you may end up with an empty page because e.g. your edit was shrinking the result set in a way that the current page doesn't exist anymore I would think that even that would be more intuitive to get a blak page than going back to page 1. Maybe it could even be implemented that, should the current page not exist anymore after the edit, only then move to the first page or even the last page of the new dataset. But not flat out jump to 1 if there is no reason for it at all - which is in our case like 99% of the time.

Just my 2 cents...

[tallmorgan]

I would understand resetting page to 1 being a design decision if the user were to change filters. But if no filters are actually in use, and the user updates a value in a row without mutation, going to page 1 does not feel like intentional design.

For a workaround, I immediately restore first on firstChange:

ngOnChanges(changes: SimpleChanges) {
  if (changes.rows) {
    // immediately restore the current page after it's reset upon updating a row
    // https://github.com/primefaces/primeng/issues/11898
    this.tableFirst = this.table.first;
  }
}

restoreTableFirst() {
  if (this.tableFirst) {
    this.table.first = this.tableFirst;
    delete this.tableFirst;
  }
}

<p-table
  [value]="rows"
  (firstChange)="restoreTableFirst()"
></p-table>

What's happening here when rows is updated:

1. Our component's ngOnChanges() stores this.tableFirst = this.table.first
2. PrimeNG's Table component's ngOnChanges() resets the page this.first = 0 and emits this.firstChange()
3. Our component restores this.table.first = this.tableFirst and deletes the latter until the next change detection

[twopelu]

This really deserves a fix by PrimeNG Team. It is a show stopper for many of us and our clients and all workarounds feel really cheap / clunky. Whenever we migrate to a newer version of Angular and PrimeNG we have to apply patch it again. Any updates from the project owners?

[twopelu]

At least we would expect this to be reopened and considered as a bug please.

[tehnorm]

Seeing the same issue here. I really would like a flag that would say something like "preserve position" and keep things on the current page vs this default behavior. The UX of this usually leads to a content flash, which is less than optimal for end users.

[barkdoll]

I would understand resetting page to 1 being a design decision if the user were to change filters. But if no filters are actually in use, and the user updates a value in a row without mutation, going to page 1 does not feel like intentional design.

For a workaround, I immediately restore first on firstChange:

...

What's happening here when rows is updated: ...

source

@tallmorgan I ran into this issue like everyone else here, and your workaround was small and elegant enough for me to just implement it and move on.

I retro-fitted it to utilize my existing state setup with an RxJS BehaviorSubject like so:

restoreTablePage(): void {
  const restore = this.first$.value;
  this.tableRef.first = (restore < this.data.length) ? restore : 0;
}

<p-table
  [value]="data"
  [rows]="10"
  [totalRecords]="data.length"
  [first]="first$ | async" <!-- here, -->
  (firstChange)="restoreTablePage()" <!-- here, -->
  (onPage)="first$.next($event.first)" <!-- and here -->
></p-table

Thank you for sharing that the Table#first input is being reassigned internally by the Table component's OnChanges hook. That was the behavior I was not understanding, and I was tearing my hair out. Next time I must do my due diligence and read the source code thoroughly. Cheers 🍻

Edit: added "RxJS observable pattern"-based implementation as alternative example.

[twopelu]

It would be great if anybody with knowledge could commit the fix for PrimeNG 10 so it can be released as a patch for those who still use old versions. The solutions above sound good to me :-) Any support or guidance from maintainers?

[twopelu]

What is worse is that I'm quite sure this bug is there in every new version from then... Could anybody confirm it? Whenever in the near future that I migrate to PrimeNG 12 or 16 or whatever I will have to patch it locally again. Please just fix it once and port it back if possible to previous versions or at least give an official solutions so the community can port it to older versions.

[Da13Harris]

This is still an issue in PrimeNG 17.

It's pretty disheartening to see that this issue is still closed even though it is clearly a design flaw. I don't necessarily expect this to be an easy fix, but it doesn't give me great confidence in PrimeNG when I see legitimate issues like this being closed rather than acknowledged and prioritized.

To be clear, this issue is made worse by using the stateStorage options. If the stored TableState includes any filters, and the user returns to the table with no changes to the data, the pagination still reverts to Page 1.

The number of workarounds people are having to employ certainly suggests that there is a logical flaw in the design. Specifically, it seems that table pagination is not being sequenced in a way that accommodates re-rendering with existing state.

[twopelu]

This is still an issue in PrimeNG 17.

It's pretty disheartening to see that this issue is still closed even though it is clearly a design flaw. I don't necessarily expect this to be an easy fix, but it doesn't give me great confidence in PrimeNG when I see legitimate issues like this being closed rather than acknowledged and prioritized.

To be clear, this issue is made worse by using the stateStorage options. If the stored TableState includes any filters, and the user returns to the table with no changes to the data, the pagination still reverts to Page 1.

The number of workarounds people are having to employ certainly suggests that there is a logical flaw in the design. Specifically, it seems that table pagination is not being sequenced in a way that accommodates re-rendering with existing state.

Thanks for the confirmation. We are migrating to PrimeNG 17 and this is bad news :-(

We were able to apply a simple fix with a couple lines of code and no impact in any of the features we use in the table.

I wish the maintenance team of PrimeNG reconsider it and we get this fixed properly, but after 7 versions I really dont think that is going to happen unluckily :(