-
Notifications
You must be signed in to change notification settings - Fork 60
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
ApolloPagination
usage docs
#262
Conversation
👷 Deploy request for eclectic-pie-88a2ba pending review.Visit the deploys page to approve it
|
652cfb8
to
9162553
Compare
ApolloPagination
to DocC generation, generate short Introduction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an awesome start! I've got a few minor suggestions and questions.
I also want to start a running list of things to be added to documentation (can be done in the future):
- Example of Reverse/Bidirectional Pagination
- Example of Offset based pagination
- Example of using different queries for initial query vs additional pages
Happy to address these – @AnthonyMDev do you have advice for running this locally, so I can see how the changes would present on the web? I wasn't able to get it running locally, which certainly made things a little tougher. |
Our docs deployment repo is actually public, so you can clone it, and then use the instructions here to run the docs locally. |
mvp |
ApolloPagination
to DocC generation, generate short Introduction
ApolloPagination
usage docs
cc: @AnthonyMDev I've gone ahead and added 3 more pages & added a single example of an offset pager within the Introduction. However, in writing the offset docs, i recognized there are some improvements and conveniences afforded to cursor pagination that are not extended out to offset. I'll correct that shortly. |
c170b7e
to
30529e8
Compare
@@ -27,7 +27,7 @@ public extension GraphQLQueryPager { | |||
client: ApolloClientProtocol, | |||
watcherDispatchQueue: DispatchQueue = .main, | |||
initialQuery: InitialQuery, | |||
pageResolver: @escaping (P, PaginationDirection) -> InitialQuery, | |||
pageResolver: @escaping (P, PaginationDirection) -> InitialQuery?, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AnthonyMDev I can pull this out of this PR if you prefer and into a second – but I noticed that the pageResolver
wasn't expecting an Optional<InitialQuery>
in the GraphQLQueryPager
definitions, but was in the AsyncGraphQLQueryPager
definitions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, that's fine!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, reading through these docs, this library is just so incredibly feature rich already! What an awesome job @Iron-Ham!
Couple of edits to add some more information and minor fixes!
client: client, | ||
initialQuery: initialQuery, | ||
pageResolver: { page, paginationDirection in | ||
// As we only want to support forward pagination, we can return `nil` for reverse pagination |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the convenience functions that only support single direction paging, can we just omit the pagination direction from the pageResolver
closure signature? It should only be needed for bidirectional paging, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed this on our call just now – but this can be an improvement for 0.2.x
We could do it by declaring ForwardPageInfo
and ReversePageInfo
protocols, and then declaring the convenience functions around those protocols.
|
||
## Forward Pagination | ||
|
||
Forward pagination is the most common form of pagination. It is used to fetch the next `n` items in a list. We can use the convenience `make` functions to create a configured `GraphQLQueryPager`. While we have many options depending on our requirements -- whether we use one query or two, whether we want to use a cursor or an offset, whether we want to transform the results, etc. -- we will examine using a cursor with a single query. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's talk about my question related to omitting paginationDirection
in single directional convenience functions. If we can go that route, then I have some suggestions to tweak this.
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
Co-authored-by: Anthony Miller <[email protected]>
@@ -237,6 +237,8 @@ public class AsyncGraphQLQueryPager<Model>: Publisher { | |||
/// Resets pagination state and cancels further updates from the pager. | |||
public func cancel() async { | |||
await pager.cancel() | |||
_subject.send(completion: .finished) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to update unit tests for this? Can also be done in a separate PR later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that'd be wise, yes.
As written, I think this would require us to re-init a new pager – in the same sense that cancelling a watcher
stops it from being used again.
|
||
## Cancelling ongoing requests | ||
|
||
The `GraphQLQueryPager` class provides a `cancel` method, which can be used to cancel any ongoing fetch operations as well as cease all subscriptions. Once cancelled, the pager's state is reset. Any subscriber that was subscribed to the pager will receive a termination signal, and will no longer receive updates. After calling the `cancel` method, you msut resubscribe to the pager in order to receive updates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The `GraphQLQueryPager` class provides a `cancel` method, which can be used to cancel any ongoing fetch operations as well as cease all subscriptions. Once cancelled, the pager's state is reset. Any subscriber that was subscribed to the pager will receive a termination signal, and will no longer receive updates. After calling the `cancel` method, you msut resubscribe to the pager in order to receive updates. | |
The `GraphQLQueryPager` class provides a `cancel` method, which can be used to cancel any ongoing fetch operations as well as cease all subscriptions. Once cancelled, the pager's state is reset. Any subscriber that was subscribed to the pager will receive a completion signal, and will no longer receive updates. After calling the `cancel` method the pager is invalid. You will need to create a new pager in order to receive updates again. |
14038690 usage docs (#262) git-subtree-dir: apollo-ios-pagination git-subtree-split: 1403869013cfbe8cdf565cec39744d24b447fba7
git-subtree-dir: apollo-ios-pagination git-subtree-mainline: bda25cd git-subtree-split: 1403869013cfbe8cdf565cec39744d24b447fba7
This PR added
ApolloPagination
to the list of valid targets for theDocumentationGenerator
command. I added theApolloPagination
package as a dependency of the project.NOTE: I am receiving the following warning –
This PR also adds a new pagination entry in the sidebar & a short intro md.
For now, I've left the visibility of the pagination entry as
false
.I wasn't able to get this running locally, so I have no clue what this would look like in the doc portal.