-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEAT]: Give user control to stop pagination earlier #165
Comments
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with |
Describe the need
Use case
The default behavior right now is to paginate through all pages always. However, in certain cases users may want to stop the pagination earlier. For example, it could be useful to stop after a certain number of pages or to stop after a particular item shows up in the results. This use case can be solved by using the
iterator
function/interface, but it then forces the users to do manual merging on their end, which reduces the benefit of using this plugin.Prior art
The REST plugin provides such a control mechanism via a
mapFunction
parameter. However, it's called amapFunction
even though it actually serves 2 purposes: mapping/transforming and stopping early. In GraphQL world, mapping/transforming is not necessary nor expected.Proposal
Add a
stopFunction
as the third argument toiterator
andpaginate
. After each page is fetched, the function will be invoked with two parameters, first is the response of the most recently fetched page, and the second is adone
function that stops the iteration if invoked.The usage scenarios would be covered like the following snippets.
Alternative implementation
Instead modeling after the REST plugin's API, we could just add an
options
object as the third argument and allow users to pass in more explicit "stop conditions". For example:This could allow other options to be added in the future so it's more extensible. But this will also mean that there is a divergence in API between REST and GraphQL paginate plugins.
Related PR
#163
SDK Version
No response
API Version
No response
Relevant log output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: