Skip to content

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

@Yacodo

Description

@Yacodo

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 ?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions