You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I have to re-implement all of filtering/sorting when I really only want to change pagination.
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.
The text was updated successfully, but these errors were encountered:
Currently, the only type of pagination available uses
page
andpageSize
. 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 usingtop
andskip
(the Microsoft API Guidelines for client-side pagination). And it's impossible to convert fromtop
andskip
topage
andpageSize
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.ISieveModel
interface definespage
andpageSize
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 fromSieveProcessor
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.The text was updated successfully, but these errors were encountered: