question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Erroneous warning when using imperative API

See original GitHub issue

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!

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:1
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
helfercommented, Mar 17, 2017

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?

1reaction
bensalilijamescommented, Mar 17, 2017

Sure - one repo coming up.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found