Add depth traversal to `simplifyParsedResolveInfoFragmentWithType`

[andyrichardson]

Feature description

Currently, simplifyParsedResolveInfoFragmentWithType will only return fields that match the type on the root of the ResolveTree.

It would be great if instead, the function would iterate through the resolve tree to collect all fields requested for a given type.

Motivating example

Consider the following schema

type Query {
  things: ThingConnection!
}

type ThingConnection {
  edges: [ThingEdge!]!
}

type ThingEdge {
  node: Thing!
  cursor: String!
}

type Thing {
  id: ID!
}

Typically, a resolver would be added to the field Query.things to get a paginated list of things.

The resolver needs to know the selection set for the Thing type, so it might do something like this.

(node, args, ctx, info) => {
  const parsedInfo = parseResolveInfo(info);
  const { fields } = simplifyParsedResolveInfoFragmentWithType(parsedInfo, 'Thing') 
}

This won't work however because the selection set of the desired type are not at the root of the resolveInfo. Instead this would be required

(node, args, ctx, info) => {
  const parsedInfo = parseResolveInfo(info);
  const { fields } = simplifyParsedResolveInfoFragmentWithType(parsedInfo.fieldsByTypeName.ThingConnection.edges.fieldsByTypeName.ThingEdge.node, 'Thing') 
}

This becomes grows in complexity if a union or interface is used further up in the tree like this

type ThingEdge {
  edges: [ThingUnion!]!
}

Solution

Something like getFieldsForTypeInResolveInfo which iterates through the resolve info and returns all fields that match a given type within the resolve info

(node, args, ctx, info) => {
  const parsedInfo = parseResolveInfo(info);
  const fields = getFieldsForTypeInResolveInfo(parsedInfo, 'Thing') 
}

Breaking changes

N/A

Supporting development

I [tick all that apply]:

• [x] am interested in building this feature myself
• [x] am interested in collaborating on building this feature
• [x] am willing to help testing this feature before it's released
• [x] am willing to write a test-driven test suite for this feature (before it exists)
• [x] am a Graphile sponsor ❤️
• [ ] have an active support or consultancy contract with Graphile

[benjie]

Hi Andy, you didn't share a query to go with the schema, but I think I see what you mean. If I've interpreted your question correctly then your proposed solution isn't really safe in general, for example:

extend type Thing {
  relatedThings: [Thing!]
  name: String
  bigComplexObject: JSON
}

Now a query like

{
  things { edges { node {
    id
    bigComplexObject
    relatedThings {
      id
      name
    }
  } } }
}

Here we want bigComplexObject for just the root level things, and name just for the related things; but if we were to recurse we'd collect both sets. You could stop iterating when you hit the type, but that still opens up other routes for failure, for example if you extended the connection type and added a related but different field:

extend type ThingCollection {
  myThings: [Thing]
}

then having the root connection collect these together would be wrong. I wonder if something more along the lines of "resolve the tree at this query path" would make sense, however there's complexity in that relating to aliases; e.g.

{
  things {
    # Misleading
    edges: nodes { id }

    # Extends selection of data required from the backend
    nodes2: { name }
  }
}

[andyrichardson]

Hey Benjie, appreciate the response :pray:

Totally with you - in the case of recursive type definitions, this wouldn't make sense. For our use case where there is a 1-1 relationship between the fields on an object type defined in the schema and columns on a table in our database that we want to query, this hasn't been a concern.

I'll close this for now as it seems there are too many edge cases to consider in order to make something like this viable.