List of connections don't seem to be supported correctly

[KyleAMathews]

I'm working on adding a new field to GraphQL that is a list of connections. It works perfectly when queried from GraphiQL but when I do the same query in Relay I get this error:

warning.js:44 Warning: RelayQueryWriter: Cannot write edges for connection category_cliques on record client:-1988558205148, expected a response for field `edges``

Followed by:

Uncaught Invariant Violation: RelayRecordStore.getLinkedRecordIDs(): Expected field category_cliques for record RG9tYWluOmdvb2dsZS5jb20= to have an array of linked records.

Relay seems to be assuming the list is the actual connection and is looking for a edges field (which is correctly set on the items in the list).

UPDATE:
So played around some more and if I remove the connection arguments (first/last/etc) from the list field then it starts working. So Relay has I'm assuming a heuristic for connections which looks for certain arguments and then treats the field as a connection. This makes this case a bit awkward as I want to be able to pass normal connection arguments to each of the child connections in the list. The simplest work-around here is probably to just use different argument names and then rewrite for passing to the next layer.

Is this something Relay core should fix or just ignore for now as it's a fairly edgy edge case?

[josephsavona]

@KyleAMathews Can you paste the relevant portion of the query and schema?

[KyleAMathews]

query:

{
  category_cliques(first: 5) {
    primary_title
    total
    date_histogram {
      quarter_start
      cumulative_count
    }
    flow {
      time_period
      count
    }
    edges {
      node {
        name
        domain
        relationships(types: ["vendor"]) {
          created_at
        }
      }
    }
  }
}

schema:

{
  "name": "category_cliques",
  "description": null,
  "args": [
    {
      "name": "after",
      "description": null,
      "type": {
        "kind": "SCALAR",
        "name": "String",
        "ofType": null
      },
      "defaultValue": null
    },
    {
      "name": "first",
      "description": null,
      "type": {
        "kind": "SCALAR",
        "name": "Int",
        "ofType": null
      },
      "defaultValue": null
    },
    {
      "name": "before",
      "description": null,
      "type": {
        "kind": "SCALAR",
        "name": "String",
        "ofType": null
      },
      "defaultValue": null
    },
    {
      "name": "last",
      "description": null,
      "type": {
        "kind": "SCALAR",
        "name": "Int",
        "ofType": null
      },
      "defaultValue": null
    }
  ],
  "type": {
    "kind": "LIST",
    "name": null,
    "ofType": {
      "kind": "OBJECT",
      "name": "CliqueConnection",
      "ofType": null
    }
  },
  "isDeprecated": false,
  "deprecationReason": null
},

[josephsavona]

Which field is the list of connections? That just looks like a normal collection (?).

[KyleAMathews]

category_cliques

In graphql-js, I create it with type: new GraphQLList(require("./connections/clique-connection"))

[josephsavona]

Got it, i see it in the schema now.

You're correct that Relay has a heuristic for detecting connections - it's based on the type name (ends in "Connection"), the existence of connection-like fields, and the presence of edges and page info fields. Relay also assumes that connection fields are scalars, so if you need a list of them, you might have to create an intermediate object in the schema:

category_cliques { # List[CategoryClique]
  cliques(first: $n) { ... } # scalar connection
}

[KyleAMathews]

K, closing this as "works as expected". Thanks!

[josephsavona]

Cool, thanks for following up here.

[jeromecovington]

Does Relay have a heuristic for detecting type names that end in "Item"?

[wincent]

I don't think so, @jeromecovington.

Generally heuristics aren't fun. The Connection heuristic was born out of how connections emerged historically at Facebook, but I don't think we would have necessarily designed them that way in Relay if we didn't have the historical precedent with which to maintain compatibility. Ideally you'd be able to name them anything you wanted, and we'd use some other means (like schema metadata) to annotate them unambiguously as connections.

[jeromecovington]

You're right @wincent - testing in my current app seems to confirm no magic "Item".