Hey Zora peeps π , I have a question/feature request about tokens and pagination.
I want to surface token collector data for a given set of collectionAddresses. Using the tokens query, I can definitely fetch all these tokens, further filter the results (e.g. by specifying ownerAdddresses) or limit the page size to some number less than 500, but paginating through these results in a way that gives complete data for each owner within a page has proved to be trickier than I expected.
Expected Behavior
Be able to query tokens with some limit and sort/group results by owner addresses. The endCursor returned could then be used to fetch the next set of owned tokens when the client needs it.
Actual Behavior
We have no guarantee that tokens for the same owner don't exist across page breaks. e.g.
One would need to paginate through the resulting set and group tokens manually to confidently return token data for a given owner. Also, the main workarounds I can think of kind of defeat the purpose of cursor pagination π’ (see below).
Potential Workarounds
Option A: Don't paginate on the graphQL level -- i.e. exhaustively query for all tokens & map owners to their NFTs on the client-side as mentioned above.
Works, but wouldn't scale well for collections with lots of holders/tokens.
Option B: Get all owner count data first (e.g using ownersByCount), for most cases query tokens with a subset of ownerAddresses that we can be sure are less than our limit and for cases where a single owner has >500 tokens owned, paginate through all of those results before returning our result.
Seems better, but I think sort of defeats the purpose of cursor pagination. Rather than giving the client the chance to fetch more data when it needs it via the endCursor, this kind of batches the owners we query with instead π€
Am I missing something? Would it be possible to incorporate this sort of behavior in the future? I'm all ears!
Background & Context
Hey Zora peeps π , I have a question/feature request about tokens and pagination.
I want to surface token collector data for a given set of
collectionAddresses
. Using thetokens
query, I can definitely fetch all these tokens, further filter the results (e.g. by specifyingownerAdddresses
) or limit the page size to some number less than 500, but paginating through these results in a way that gives complete data for each owner within a page has proved to be trickier than I expected.Expected Behavior
Be able to query
tokens
with somelimit
and sort/group results byowner
addresses. TheendCursor
returned could then be used to fetch the next set of owned tokens when the client needs it.Actual Behavior
We have no guarantee that tokens for the same owner don't exist across page breaks. e.g.
One would need to paginate through the resulting set and group tokens manually to confidently return token data for a given owner. Also, the main workarounds I can think of kind of defeat the purpose of cursor pagination π’ (see below).
Potential Workarounds
Works, but wouldn't scale well for collections with lots of holders/tokens.
Seems better, but I think sort of defeats the purpose of cursor pagination. Rather than giving the client the chance to fetch more data when it needs it via the
endCursor
, this kind of batches the owners we query with instead π€Am I missing something? Would it be possible to incorporate this sort of behavior in the future? I'm all ears!