__typename no longer implicitly included in results

[hendrikniemann]

Since upgrading to urql 4 and graphcache 6, __typename does not longer appear in the results of a mutation automatically. It is still automatically added to the query that is sent to the server. It only appears in the result object if I explicitly add it to the selection set. I don't understand why this is the case. I have searched in all the release notes, but this does not seem to be listed anywhere. At the same time I would consider this a breaking change.

Now in theory that is not too bad, but now I have to turn the __typename fields of in the TypeScript codegen, which then leads to type errors in my graphcache updates function.

Any hint's on how I can get them back?

My setup:

createClient({
  url: import.meta.env.VITE_GRAPHQL_URL ?? "/graphql",
  exchanges: [
    devtoolsExchange,
    cacheExchange(graphCacheOptions),
    authExchange(async (utils) => { ... }),
    fetchExchange,
  ]
})

const graphCacheOptions: CacheExchangeOpts = {
  schema,
  keys: ...
  updates: ...
  resolvers: ...
};

[JoviDeCroock]

You can add an exchange that always adds __typename to every selection, similar to the one we have in our cacheExchange

[hendrikniemann]

Thanks for the quick response!
I am not sure if that is the problem. The _typename seems to be actively filtered out:

In my code:

mutation {
  createTodo(text: "khjasdfgkhj") {
    id
  }
}

Sent over the network:

mutation {
  createTodo(text: "khjasdfgkhj") {
    id
    __typename
  }
}

Result recevied from the server:

{
  "createTodo": { "id": 1, "__typename": "Todo" }
}

But in the end the typename is not part of the result of the mutation:

const [, createTodo] = useMutation(CreateTodoMutation);

onSend = () => {
  const result = await createTodo(..)
  console.log(result.data.createTodo.__typename); // -> undefined
}

[JoviDeCroock]

Yes, if you don't ask for __typename in the original query then it won't be sent back, TLDR if the cache has to add it you will lose it 😅 . so there might be a way to add it in an exchange in the front of your chain.

[hendrikniemann]

Okay, I think this makes sense. I got confused because I think this behaviour seems to have changed from 5.x to 6.x. I guess this was somewhat undocumented behaviour in graphqcache 5.x that I took for granted.

[kitten]

This was indeed undocumented. To be very honest with you, I think I may have broken this small feature twice over before the right combination of tests caught it. We also changed how this is done to prevent it from breaking again.

The reason why people initially complained is that TypeScript wouldn't warn them about the added property. So, you could have a rest spread and it would say that it matches a given mutation input but the added property would break on server validation.
Not that I endorse trusting spreads blindly for mutation inputs...

But, I overall support the idea that a normalised cache should give you the exact shape of data that you asked for.

If that doesn't integrate well with a current GCG plugin that's entirely unintentional though 😅

[hendrikniemann]

So for others having a similar problem I want to document my solution here. Having the __typename field always present can be very useful, e.g. in the update functions after Mutations. We make use of interfaces for mutation results, so for a cache update it is essential to understand if a mutation was successful.

GraphQL Code Generator "client preset" seems to provide an option for including __typename always within the types. The option is nonOptionalTypename. But this option does not seem to affect the generated parsed documents. Instead, I found a solution using the so called document transforms:

const config: CodegenConfig = {
  "...": {
    documentTransforms: [
        {
          transform: ({ documents }) => {
            // Add __typename to all SelectionSets
            return documents.map((documentFile) => {
              if (documentFile.document) {
                documentFile.document = visit(documentFile.document, {
                  SelectionSet: {
                    leave(node) {
                      if (
                        !node.selections.some(
                          (selection) =>
                            selection.kind === "Field" && selection.name.value === "__typename",
                        )
                      ) {
                        return {
                          ...node,
                          selections: [
                            ...node.selections,
                            {
                              kind: "Field",
                              name: {
                                kind: "Name",
                                value: "__typename",
                              },
                            },
                          ],
                        };
                      }
                    },
                  },
                });
              }
              return documentFile;
            });
          },
        },
      ],
    }
  }
};

This visitor will add the __typename field to every selection set. The result is that for URQL, it looks like the application developer included the field and therefore the fields are always returned.