Erroneous warning when using imperative API

When running commands from the new imperative API, I get this warning:

You're using fragments in your queries, but don't have the addTypename:
true option set in Apollo Client. Please turn on that option so that we can accurately
match fragments.

fragmentMatcher	@	readFromStore.js?25f66d2:29
(anonymous)	@	graphql.js?7a56643:49
executeSelectionSet	@	graphql.js?7a56643:26
(anonymous)	@	graphql.js?7a56643:88
executeSubSelectedArray	@	graphql.js?7a56643:81
...

However, I have ensured that addTypename: true in the client setup:

const client = new ApolloClient({
  ssrMode: IS_SERVER,
  addTypename: true,
  dataIdFromObject: (result) => {
    if (result.id && result.__typename) {
      return result.__typename + result.id;
    }
    return null;
  },
  networkInterface,
});

The specific command I’m running is:

update: (proxy, mutationResult) => {
  const data = proxy.readQuery({
    query: graphQuery,
  });

  data.nodes.push(mutationResult.data.createNode);

  proxy.writeQuery({
    query: graphQuery,
    data,
  });
},

Intended outcome:

Not to display the warning, or perhaps I’m doing something wrong!

[helfer]

Thanks a lot @benhjames, this was extremely helpful. I now know what’s going on.

First, there was a small problem in your code: you forgot to add __typename in the optimistic result. Adding that alone didn’t fix the issue because of the second problem:

proxy.writeQuery doesn’t check addTypename, which means the result would be written to the store without the __typename field, even if it was present on the result.

I think the proper thing to do here is to make writeQuery and writeFragment (and also the read functions, actually) respect addTypename. Once we have non-heuristic fragment matcher (hopefully next week), we can also start throwing errors if fields are missing during a write.

@calebmer do you have time to update the direct store API so it respect addTypename?

[bensalilijames]

Sure - one repo coming up.