Skip to content

Paginator does not "reset" when new length is smaller than the previous shown length #5812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Laurensvdw opened this issue Jul 17, 2017 · 7 comments
Assignees
Labels
needs: discussion Further discussion with the team is needed before proceeding

Comments

@Laurensvdw
Copy link

Laurensvdw commented Jul 17, 2017

Bug, feature request, or proposal:

Reset paginator when the length property has changed, or provide a method we can call to do the reset manually.

What is the expected behavior?

Going back to pageIndex 0

What is the current behavior?

Page remains the same even if the length provided is smaller than pageIndex(+1) * pageSize

What are the steps to reproduce?

Go to a page in your data which has a range greater then the length of data after filtering.
E.g. (PageSize: 10) results 20-30 are shown, then when pressing some kind of filter you only have a length of results of 4 in total. It will show something like 20-24 (while it should be 1-4, and on pageIndex: 0)
image

What is the use-case or motivation for changing an existing behavior?

When having a use-case which is more 'complex' than paginating over a simple data set, the current paginator is not usable.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Latest version

@andrewseguin andrewseguin self-assigned this Jul 17, 2017
@andrewseguin
Copy link
Contributor

We intentionally did not design the paginator to adjust the page index automatically on length changes because there is not a consistent rule to follow here.

For example, let's say that the length is 100 and the user is on the last page looking at items 90-100.

  • If the length changes due to a database change and the list is now 95 items, the user will likely still want to see the last page with items 90-95.
  • If the length changes due to a filter input and reduces to 25 items, then it's likely the user is searching and wants to now be at the first page of the results.

In each case, it is up to the developer to decide how to adjust the page index.

In your case, when the user triggers a filter change, always set the paginator's page index to 0. This can be done by getting the paginator through @ViewChild(MdPaginator) paginator: MdPaginator and setting the page index with this.paginator.pageIndex = 0;

For an example of this type of logic, check out this table's data source which listens for filter changes and resets the page index in response: https://plnkr.co/edit/LZ9HQnCKrmXm0g2vqVGH?p=preview

@Laurensvdw
Copy link
Author

Hello Andrew,

That makes complete sense! I thought there would be some kind of method to provoke the 'reinitialization' of the paginator, however your approach makes more sense due to added flexibility. Thanks for the clarification!

@gowthamrodda
Copy link

Thanks a lot andrewseguin. Your answer saved my time.

@bhelzer
Copy link

bhelzer commented Oct 13, 2017

The answer is great, I wish the documentation would say this upfront. Seems like this is common if you have a filter on the table.

@nagabhushanbn
Copy link

Thanks a lot for the solution!

@pablomusumeci
Copy link

Why is this.paginator.pageIndex = 0; preferred over this.paginator.firstPage();

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019
@mmalerba mmalerba added the needs: discussion Further discussion with the team is needed before proceeding label Mar 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs: discussion Further discussion with the team is needed before proceeding
Projects
None yet
Development

No branches or pull requests

7 participants