flask-resty
flask-resty copied to clipboard
pagination doesn't return total page number or total query number
Currently (version 0.21.1) the pagination is returning only has_next_page field in the meta
{
"data": [],
"meta": {
"has_next_page": true
}
}
But this is useless in terms of displaying a pagination control in the frontend. (https://getbootstrap.com/docs/4.3/components/pagination/)
The frontend has to know to total number of pages or items, in order to render properly.
Jeffery
@taion can correct me if I'm wrong here but I think the idea is to optimize for cursor-based pagination as opposed to offset-based. You can subclass PaginationBase to implement any pagination technique you'd like.
Some background:
https://slack.engineering/evolving-api-pagination-at-slack-1c1f644f8e12 https://graphql.org/learn/pagination/#pagination-and-edges
It might make sense to add this as an extension or mixin. We don't do this by default because evaluating this sort of COUNT(*) requires at least doing an index-only scan over all the relevant roles.
When we're doing something like infinite scroll pagination, it's not something we end up directly needing on the pages themselves. When we do need overall counts, we tend to put these on parents.
I do agree that this is an oversight, though.
All right. I've implemented my Pagination sub-class that returned the required information
from flask_resty import PagePagination
from flask_resty import meta
import flask
class MyPagePagination(PagePagination):
page_size = 'page_size'
def get_page(self, query, view):
# allow frontend to update page_size
page_size= flask.request.args.get(self.page_size)
if page_size:
self._page_size = int(page_size)
# return pagination info
meta.update_response_meta({"total": query.count()})
meta.update_response_meta({"current_page": self.get_request_page()})
meta.update_response_meta({"page_size": self._page_size})
return super().get_page(query, view)
Let me know what you think about it.
Yeah, that looks pretty good. I think maybe we want to make this an option for the relevant pagination components. You can see that e.g. this requires another database query to get the total count, which was why we didn't include it by default, but it seems like useful functionality to have.
The additional query is fine, as normally you will have caching on the server side with flask-caching
Yeah, that looks pretty good. I think maybe we want to make this an option for the relevant pagination components. You can see that e.g. this requires another database query to get the total count, which was why we didn't include it by default, but it seems like useful functionality to have.
Yeah, that makes sense. What do you think of PRing this as an optional thing in our pagination classes?
That's fine. What's the name of this class you suggest?