Skip to content
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

Support for non-breaking change of RelayedFieldResolver({ paginationInputType }) (?) #72

Open
Yacodo opened this issue Nov 8, 2021 · 0 comments

Comments

@Yacodo
Copy link
Contributor

Yacodo commented Nov 8, 2021

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 ?

@Yacodo Yacodo changed the title Support for non-breaking transition of RelayedFieldResolver({ paginationInputType }) (?) Support for non-breaking change of RelayedFieldResolver({ paginationInputType }) (?) Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant