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!
Hi @benhjames. I'm not sure what's going on in your case. Could you try to reproduce the error with https://github.com/apollographql/react-apollo-error-template please?
Sure - one repo coming up.
Behold, in all its glory:
https://github.com/benhjames/react-apollo-error-template
Hopefully the fact that I didn't write the mutations in the backend doesn't matter - this was sufficient to still repro the warning appearing!
Just start the app, and click the button "Click me to make error", and observe the warning in the console, despite using addTypename: true.
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?
Nice one, glad it was useful! Thanks for spotting the missing __typename in the optimistic result too, will save me some head-scratching down the line. 😃
This is fixed.