Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Pagination Customization #121

Closed
avalara-stephen-hickey opened this issue Mar 10, 2021 · 0 comments
Closed

Pagination Customization #121

avalara-stephen-hickey opened this issue Mar 10, 2021 · 0 comments

Comments

@avalara-stephen-hickey
Copy link

avalara-stephen-hickey commented Mar 10, 2021

Currently, the only type of pagination available uses page and pageSize. There are other ways pages may want to be defined that are not available because of this implementation detail. For instance, it's impossible to get the same results if I wanted to paginate using top and skip (the Microsoft API Guidelines for client-side pagination). And it's impossible to convert from top and skip to page and pageSize because the result sets are different (due to integer division).

It's possible to make my own SieveProcessor to make this work, but there are a couple of issues with this.

  1. I have to re-implement all of filtering/sorting when I really only want to change pagination.
  2. The ISieveModel interface defines page and pageSize which may be unused if using a different sort method.

I think a quick fix to make this easier would be to make the ApplyPagination, ApplyFiltering, ApplySorting methods protected and virtual. This would let users inherit from SieveProcessor and only have to override the methods they care about changing. This fixes issue 1 and would not be a breaking change.

To fix issue 2, however, would probably be a breaking change, because it would require a change to ISieveModel, although would be a good path forward for the next major version. Changing the interface to use Skip and Take would allow more flexibility for both cases (you can convert skip/take => page/pageSize, but not vice versa), but I think implementing a pagination interface would be more ideal, because it could allow other types of paging as well, such as server driven pagination.

Repository owner locked and limited conversation to collaborators May 16, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants