You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 parameterpagination: 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 ?
The text was updated successfully, but these errors were encountered:
Yacodo
changed the title
Support for non-breaking transition of RelayedFieldResolver({ paginationInputType }) (?)
Support for non-breaking change of RelayedFieldResolver({ paginationInputType }) (?)
Nov 8, 2021
Request feature
Use-case
We had a resolver using
RelayedFieldResolver::paginationInputType: false
which printed as: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:But while this was working fine, we find out that the result of the
ResolverConnectionArgs.pageInfo
would be based only onpagination
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 ?
The text was updated successfully, but these errors were encountered: