Erroneous warning when using imperative API
See original GitHub issueWhen 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!
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Alert should be implemented as a component, rather than an ...
I guess this component would wrap the native imperative Alert and ActionSheet API. Yes, at least in the first iteration. I can imagine...
Read more >Imperative API | Format.JS
Allows the user to provide a custom error handler. By default, error messages are logged using console.error if NODE_ENV is not set to...
Read more >Centralizing API error handling in React apps - ITNEXT
In this article I'm going to present to you a way of handling your API errors once and for all in a centralized...
Read more >How to imperatively handle an error, with react-query?
Have you tried using the onError callback? It looks like this : const useTodos = () => useQuery(['todos'], fetchTodos, { // ⚠️ looks...
Read more >Error Handling Patterns in Amazon API Gateway and AWS ...
The Lambda function must exit with an error in order for the response pattern to be evaluated – it is not possible to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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 checkaddTypename
, 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
andwriteFragment
(and also the read functions, actually) respectaddTypename
. 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
?Sure - one repo coming up.