Closed Muhammad-Arsalan31 closed 1 year ago
Hi, it is possible to add, but sounds like it is always uses the currentPage, therefore I'm not sure it should part of the lib...
Thanks for responding
Yes it uses the currentPage for validating the next and previous? What are your concerns about using currentPage within lib. Or do you have any other method?
currentPage
is part of the lib input, your feature request, is related to manipulating input of the lib, therefore, I don't think that it should be part of the lib.
Moreover, the lib not fetches the total
count always (which is an additional query), therefore, lastPage
is not always available, so you can't calculate nextPage
reliably.
got your point. we can also make this optional just how the lib handles total query by passing isLengthAware prop. the same can be done here with one additional prop. like hasNextAndPrevPage
it may not be best name but it can be discussed.
eg:
.paginate({ perPage: 2, currentPage: 2, isLengthAware: true ,hasNextAndPrevPage:true})
I don't want to introduce additional boolean flag for this,
I can add these fields only when last page is available, therefore, only when the query is content aware (isFromStart=true
, isLengthAware=true
, 1currentPage=1`).
Do you think that it should be added then?
I think it should be fine with it. thanks.
Released in v3.1.0
Thanks for amazing package.
Pagination should return previous page and next page .
if current page is 1 than previous page should be null if last page is null the next page should be null
eg: { total: number currentPage: number perPage: number prev: number | null next: number | null }
it will give flexibility and ease to use for pagination in tables on the front end.
I did add the next and prev page in the code but I cannot pass the tests so I am a little confused. can I submit the PR without tests I am not sure if I can fix those tests
this is how I did