[RFC] feat(paginator): add CursorPaginatorInterface
#6305
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.
This is currently a WIP and an RFC. If maintainers are open to the idea, I will complete the PR. Currently, it is missing HAL supports and the tests.
To improve cursor pagination, I propose the creation of
CursorPaginatorInterface
:A cursor is an opaque identifier embedded in the URL, that indicates a specific page. The format of this identifier is left to the implementation. The framework and the user should not care about this format, they only know that the identifier can be used to locate a page.
A future
DoctrineCursorPaginatorFactory
might use a Base64-encoded serialized array containing the edge values and sort direction.If a
ProviderInterface::provide()
returns aCursorPaginatorInterface
, API Platform will render it like this (for JSON-LD/Hydra):It reuses the same
page_parameter_name
asPartialPaginatorInterface
. My PR changes the type of thesepage
parameters from integer to string for this to work. It should still work forPartialPaginatorInterface
.Cursor pagination will be decoupled from filtering, and no longer requires filters to work.
In the future, it will be possible to create an adapter from
PaginatorInterface
andPartialPaginatorInterface
toCursorPaginatorInterface
. In which case, the page numbers will be treated the same way as cursors. Then, we'll be able to handle all the paginators using a single logic.In the future, we should also be able to remove many of the GraphQL-related special cases and simplify the code base.
Included in this PR:
CursorPaginatorInterface
CursorBasedPartialCollectionViewNormalizer
. I decided to make it separate fromPartialCollectionViewNormalizer
for simplification.OpenApiFactory
so that thepage
query parameters' type is string, not integer.CursorPagination