Request feature
Use-case
We had a resolver using RelayedFieldResolver::paginationInputType: false which printed as:
resolver(
last: Int
first: Int
after: String
before: String
): ResolverConnection!
but we switched to RelayedFieldResolver::paginationInputType: true and wanted to keep supporting previous parameters working (while deprecating them), with a little bit of extra work, which printed as:
resolver(
# DEPRECATED: ...
last: Int
# DEPRECATED: ...
first: Int
# DEPRECATED: ...
after: String
# DEPRECATED: ...
before: String
# New pagination parameter
pagination: ResolverConnectionArgs
): ResolverConnection!
But while this was working fine, we find out that the result of the ResolverConnectionArgs.pageInfo would be based only on pagination input values (and not existing first|last|... parameters), which we don't have control over.
Request
Could we have a native solution for this use-case ?
Maybe some interceptors to manage this use-case on our side ?
or a parameter to automatically manage a fallback ?
or a parameter to automatically manage a deprecation phase (true <> false) ?
What do you think of it ?
Request feature
Use-case
We had a resolver using
RelayedFieldResolver::paginationInputType: falsewhich printed as:but we switched to
RelayedFieldResolver::paginationInputType: trueand wanted to keep supporting previous parameters working (while deprecating them), with a little bit of extra work, which printed as:But while this was working fine, we find out that the result of the
ResolverConnectionArgs.pageInfowould be based only onpaginationinput values (and not existing first|last|... parameters), which we don't have control over.Request
Could we have a native solution for this use-case ?
Maybe some interceptors to manage this use-case on our side ?
or a parameter to automatically manage a fallback ?
or a parameter to automatically manage a deprecation phase (true <> false) ?
What do you think of it ?