Handle pagination on read action with GraphQL
In my read action, I have this line enabling pagination:
In the playground, I can see that the query accepts the fields limit and offset, but the query response doesn't return anything related to the pagination (see image)
23 Replies
Yeah, thats all that we return at the moment. There is an issue in ash_graphql for returning additional information IIRC
If you want to subscribe to the issue: https://github.com/ash-project/ash_graphql/issues/39
Meanwhile, I think if you change it to use the relay version, it gives more info, right?
It probably does, at the expense of being a more confusing response
Yep, using relay fixed it for me.
what specific info did you need?
For offset?
I would expect fields like current_page, limit_per_page, has_next_page?, has_previous_page? and total_pages
Yeah, makes sense š Just making sure!
Since we've got an issue tracking this, will close.
@Zach Daniel Sorry for asking for that, I know you probably already have a lot on your plate. But do you have any idea when offset pagination would be implemented in AshGraphQL?
Using relay worked fine with me, but using cursors for pagination means that I can't create numbered pages which is a requirement for the product I'm working. So, in the end, I can't use it and need to find a solution that would use offset.
Well, offset pagination is implemented, but you're asking when the additional metadata will be added?
You can get things like
total_pages by using the count that can be optionally returned
countable: true on the pagination config
has_next_page? is count > offset + limit,
current_page is (offset + limit) / limit ,
has_previous_page? is offset > 0
limit_per_page is limit
total_pages is count / limit
I think the main one you really only need something special for is has_next_page, because on our end we know if there is a next page without having to countYes, what I meant was to AshGraphQL see that the offset pagination option is enabled and so return these fields automatically in the query response
I don't think we would necessarily want to add all of those metadata fields you mentioned though
has_next_page would be useful, but the rest can be determined already without the server doing additional work
And even has_next_page can be calculated if you have countable: trueIMO, I would want to optionally select those fields, kind of like how we can currently select
count. Sometimes it's nice 1) to not have to do that in JS/whatever consumer language is, 2) avoid simple errors in calculating those things incorrectly -- DRY it up. If they're selectable fields, the server simply wouldn't have to do the work, assuming they were implemented as some kind of resolvers, right?Well, yeah
Although honestly we'd probably jsut do the work
its just some multiplication
š
or division or w/e
I mean, not specifically all those fields, but the typical calc ones that you'd consume in a front-end for pagination UI.
š¤ well, I can add
has_next_page for now because that one actually contains an optimization that only the server can know aboutEven returning the count/limit in the query (even though it's known as the parameter) can be nice in the result because depending on the UI component API, that info might be opaque in places that only the results were being passed down.
I get what you're saying about the other fields, and its a backwards compatible change to add them
Again, the idea of it being top-level optional fields like
count means it doesn't have to run/return if the user doesn't ask for it.Yeah, but it also encourages them to ask the server to do work that it doesn't have to do
The technically most optimal thing is for the client to compute it if they want to
its yak shaving at this point, it takes like a picosecond to add and divide two integers š
Yeah, that's my take. Could always make it optional too, so those that don't want to serve that data can disable it.
but I just pushed support for
has_next_page up.
If someone wants to add those other fields, the places I just edited can be modified to support all the other fields š PRs welcome!Yeah, now that I think about it, it makes sense š
I will take a look after work
I'll probably do that in a month or two when I start getting more into supporting GraphQL at work. I know that will be asked for by my end users. lol