GraphQL support for Gridsome (and maybe Gatsby)

[wbrowar]

Performing a GraphQL query in Gridsome returns a __typename error indicating that the schema might not be defined in a way that Gridsome can accept.

This query in Gridsome’s GraphQL explorer:

  query {
    craft {
      seomatic {
        metaTitleContainer
      }
    }
  }

Results in this error:

{
  "errors": [
    {
      "message": "__typename did not match an object type: seomatic",
      "stringified": "__typename did not match an object type: seomatic\n\nGraphQL request:3:5\n2 |   craft {\n3 |     seomatic {\n  |     ^\n4 |       metaTitleContainer"
    }
  ],
  "data": {
    "craft": {
      "seomatic": null
    }
  }
}

---

One thing to note here is that when Craft is defining their interfaces and the types of arguments that can be passed in to a query, some types are defined within square brackets (perhaps this indicates they are looking for an array?). For example, looking at the schema for an entries() query in GraphQL Playground’s DOCS tab, it looks like this:

entries(
  id: [Int]
  uid: [String]
  status: [String]
  archived: Boolean
  ...etc...
): [craft_EntryInterface]

The schema for seomatic() looks like this:

seomatic(
  uri: String
  siteId: Int
  asArray: Boolean
): craft_SeomaticInterface

Note: the craft_ prefix is just the type prefix used by Gridsome.

[khalwat]

At this point, I'm not sure if this is an issue with SEOmatic, an issue with Gridsome, or an issue with the GraphQL implement in Craft CMS.

[dbrookes]

I'm seeing the same thing with Gatsby, seomatic is in the schema but errors when running the query:

  "errors": [
    {
      "message": "__typename did not match an object type: seomatic",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "craft",
        "seomatic"
      ],
      "stack": [
        "Error: __typename did not match an object type: seomatic",
        "    at new CombinedError (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/stitching/errors.js:83:28)",
        "    at Object.checkResultAndHandleErrors (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/stitching/errors.js:101:15)",
        "    at CheckResultAndHandleErrors.transformResult (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/transforms/CheckResultAndHandleErrors.js:10:25)",
        "    at /Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/transforms/transforms.js:19:54",
        "    at Array.reduce (<anonymous>)",
        "    at applyResultTransforms (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/transforms/transforms.js:18:23)",
        "    at /Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:102:50",
        "    at step (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:40:23)",
        "    at Object.next (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:21:53)",
        "    at fulfilled (/Users/dbrookes/Sites/site/homepage/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:12:58)",
        "    at process._tickCallback (internal/process/next_tick.js:68:7)"
      ]
    }
  ],

[rjgux]

Having the same issue as #487 (comment) in Gatsby

[dangayle]

There's a fix for this upstream, needs to be implemented by plugin developers: craftcms/cms#5067

[khalwat]

This is a different issue @dangayle

So SEOmatic (and Retour) both register Interfaces -- which define generators that return objects for GraphQL to use.

The issue is here:

https://github.com/craftcms/cms/blob/develop/src/services/Gql.php#L232

            // Create a pre-built schema if that's what they want.
            $interfaces = [
                EntryInterface::class,
                MatrixBlockInterface::class,
                AssetInterface::class,
                UserInterface::class,
                GlobalSetInterface::class,
                ElementInterface::class,
                CategoryInterface::class,
                TagInterface::class,
            ];
            foreach ($interfaces as $interfaceClass) {
                if (!is_subclass_of($interfaceClass, InterfaceType::class)) {
                    throw new GqlException('Incorrectly defined interface ' . $interfaceClass);
                }
                /** @var GeneratorInterface $typeGeneratorClass */
                $typeGeneratorClass = $interfaceClass::getTypeGenerator();
                foreach ($typeGeneratorClass::generateTypes() as $type) {
                    $schemaConfig['types'][] = $type;
                }
            }

Craft iterates through a hard-coded list of Interfaces, and generates the the types for them... but since plugins are not given a chance to be added to said hard-coded list, they fail.

This is a "soft error" in the GraphQL implementation in Craft, but the Apollo layer added via Gatsby and Gridsome do additional type checking to ensure that the returned data matches a registered type:

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var graphql_1 = require("graphql");
function resolveFromParentTypename(parent, schema) {
    var parentTypename = parent['__typename'];
    if (!parentTypename) {
        throw new Error('Did not fetch typename for object, unable to resolve interface.');
    }
    var resolvedType = schema.getType(parentTypename);
    if (!(resolvedType instanceof graphql_1.GraphQLObjectType)) {
        throw new Error('__typename did not match an object type: ' + parentTypename + ' -- ' + JSON.stringify(schema));
    }
    return resolvedType;
}
exports.default = resolveFromParentTypename;
//# sourceMappingURL=resolveFromParentTypename.js.map

...which fails, throwing an error.

I manually added my SeomaticInterface to the hard-coded list above, and everything worked peachy:

Ref: craftcms/cms#5149

[dangayle]

@khalwat Isn't that what Andris mentions here?

craftcms/cms#5067 (comment)

[khalwat]

Nope, it's not @dangayle

[dangayle]

ok, my apologies for misunderstanding the issue

[khalwat]

No biggy. They look similar, but the underlying issue is a different one.

[andris-sevcenko]

This will be fixed in the next Craft release. Thanks for doing the legwork!

[khalwat]

Andris fixed this in craftcms/cms@4381b1c

I'll leave this open until the fixed version of Craft is released.

[khalwat]

This was fixed in Craft CMS 3.3.13, released today -> https://github.com/craftcms/cms/blob/develop/CHANGELOG-v3.md#3313---2019-10-23