Intended outcome: The Query component returns no data after the cache was updated.
Actual outcome: Some kind of error or at least a warning saying "Cannot read query because not all data is available in the cache".
How to reproduce the issue:
I had the issue when I fired a mutation that changed data used by a Query component. In that mutation, I added some data used in that query (new entry in a list) . But unfortunately, I did not include all properties that are requested by the Query. So the Query component could not read the data from cache after the mutation was finished.
So, the Query was updated with empty data. I had a hard time finding the error I made. So I think it would be nice to have some kind of hint what went wrong.
I only found the error when I used the proxy.readQuery in the mutation's update prop. It threw an error saying "Cannot read from cache" or something.
Example:
Query read with Query component:
query queryOnQueryCompontent {
readItemList {
_id
items {
_id
prop1
prop2
}
}
}
Mutation component (Note that prop2 is missing):
mutation addItemToList($data: Data!) {
addItem(data: $data) {
_id
name
prop1
list {
_id
items {
_id
}
}
}
}
Let's assume, the item added to the list is part of the list requested by the query above and that the item's list property resolves to exactly that list.
So, before the mutation the cache for the list would look something like this:
{
"_id": "list",
"items": [
{ "_id": "item1", "prop1": "item1-prop-1", "prop2": "item1-prop2" },
{ "_id": "item2", "prop1": "item2-prop-1", "prop2": "item2-prop2" }
]
}
After the cache update, it would look like this:
{
"_id": "list",
"items": [
{ "_id": "item1", "prop1": "item1-prop-1", "prop2": "item1-prop2" },
{ "_id": "item2", "prop1": "item2-prop-1", "prop2": "item2-prop2" },
{ "_id": "new-item", "prop1": "new-item-prop-1" }
]
}
Now, the Query can't read all it's data from the cache. But instead of notifying anybody, it silently fails, returning no data at all.
If you try to read the query from cache, however, you will get an error.
I think it would be good to populate the information that a query could not be read to the client. Either by printing a warning into the console or by populating the query's error with some data.
Version
I have the same problem, thanks for the write up 馃憤
i just downgrade my apollo client from 2.5.3 to 2.3.5 and its works
Hi, I just had the same issue as well when I updated all my dependencies...
data in QueryMy versions:
"apollo-cache": "^1.1",
"apollo-cache-inmemory": "^1.3.6",
"apollo-client": "2.4.2",
"apollo-link": "^1.2.3",
"apollo-link-http": "^1.5.5",
"react-apollo": "^2.2.4",
My Client config:
import { ApolloClient } from 'apollo-client';
import { InMemoryCache } from 'apollo-cache-inmemory';
import { HttpLink } from 'apollo-link-http';
const client = new ApolloClient({
link: new HttpLink({ uri: 'http://127.0.0.1:8000/api/graphql' }),
cache: new InMemoryCache()
});
export default client;
Unfortunately, manually optimizating the cache with writeQuery or writeData is a double edged sword. Do it wrong and there is no way a Query could tell you that you did it wrong.
Unfortunately, manually optimizating the cache with writeQuery or writeData is a double edged sword. Do it wrong and there is no way a Query could tell you that you did it wrong.
Sorry, but "manually optimizing the cache" isn't the main reason people use writeQuery. The main reason that it is used is to ensure the correct values are actually in the cache after a mutation. It's not just a "nice thing to do", but an absolute requirement in a lot of cases.
As far as I can tell, I'm doing absolutely everything according to the documentation, and this still happens to me. I am trying to update the query for a chat channel after a user sends a message, and suddenly the query (on a different component) which gets a list of all chat channels (its own separate query) stops working and the component breaks because the data it was depending on has suddenly disappeared.
Your comment is extremely unhelpful. If you think that the people in this thread are "doing it wrong", then at the very least some updated documentation is necessary, to explain what these mysterious, undocumented pitalls are that you speak of. Otherwise, it is a bug that must be fixed.
So why is this issue closed?
@kaitlynbrown it is a clear user error to omit props for items inside a list on the payload of a mutation. The user is specifying to update the list with x items. Since prop2 was missing, it will not be queried and not be available. The list is replaced not deeply merged.
The following options are available:
writeQuery to update existing items to avoid wiping out the list gathered in cache by the rest of the app (recommended)@kaitlynbrown this issue is closed because the logged issue is not a bug, it is a user error. There is not a heuristic that could be performantly introduced to deeply traverse mutation payload documents and reconcile them with runtime cache and warn you that you made a mistake. Certainly it is something that could be built and added but that would also be something like a developer add-on tool for apollo-client. If you are interested in PRing something like that, please do so in the apollo-client as this is the repo for react integration.
Most helpful comment
Sorry, but "manually optimizing the cache" isn't the main reason people use
writeQuery. The main reason that it is used is to ensure the correct values are actually in the cache after a mutation. It's not just a "nice thing to do", but an absolute requirement in a lot of cases.As far as I can tell, I'm doing absolutely everything according to the documentation, and this still happens to me. I am trying to update the query for a chat channel after a user sends a message, and suddenly the query (on a different component) which gets a list of all chat channels (its own separate query) stops working and the component breaks because the data it was depending on has suddenly disappeared.
Your comment is extremely unhelpful. If you think that the people in this thread are "doing it wrong", then at the very least some updated documentation is necessary, to explain what these mysterious, undocumented pitalls are that you speak of. Otherwise, it is a bug that must be fixed.
So why is this issue closed?