[ApolloPagination] Additional conveniences for offset pagination #267
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While writing docs in #262, I recognized that support for offset pagination could be better. Specifically:
As such, this pull request modifies the
OffsetPagination
class to be a namespace, just likeCursorBasedPagination
. We introduce three new structs to facilitate pagination:OffsetPagination.Forward
: IntroducedOffsetPagination.Forward
structure to represent a forward pagination state. This is identical to the previous contents ofOffsetPagination
.OffsetPagination.Reverse
: IntroducedOffsetPagination.Reverse
structure to represent a reverse pagination state.OffsetPagination.Bidirectional
: IntroducedOffsetPagination.Bidirectional
structure to represent a bidirectional pagination state.With the addition of these new structures, we could now add and update convenience
make
functions for offset pagination, which add support forBidirectional
pagination – as well as add additionaltransform
options, supporting both single-model output andCollection
output.cc: @AnthonyMDev I'm glad that you pointed out the need for offset pagination docs. I've focused almost entirely on cursors, as that's what we use at GitHub. Once this is merged, I'll look into:
make
functions is quite large, and I'm concerned that it would be confusing for users to parse through them. Yes, they could filter by typing:make
followed by their directionForward
, and their pagination typeOffset
orCursor
, which will then present them with a further six possibilities: (single-query, single-query collection transform, single-query single-model transform, multi-query, multi-query collection transform, multi-query single-model transform). Perhaps for now, it's best to add it and then re-think the way that convenience initializers are exposed. Perhaps we can do something silly and make use of namespaces? Imagine a case-lessCursorPager
andOffsetPager
, with further namespaces for direction (Forward
,Reverse
, andBidirectional
, that then had the specific convenience functions available? This can be an improvement for later.