Data is undefined when loaded from cache

I know this issue has been talked over and over again, since the old archived repository react-apollo.

But I don’t really understand why there hasn’t been a proper solution. I mean, we all kinda expected when there’s a cache hit, data to represent that cache hit’s data. So, why the implementation does not support that?

Unless, there’s a detail that I missed and I’m clearly being ignorant in regards to the issue. Although, reading tons of those issues, did not really give me any clarification over why this keeps happening. 😛 So, I thought making a separate issue just to have a thorough explanation and see if I’m missing something was a good reason to make one.

Why when you load from cache and there’s a hit, the cache’s result is not returned to data like it would with network-only result? Instead, loading is false, but data is also undefined. Why is that the intended behavior? Who does that help and what use cases does it represent? And if its such a common problem that it has been discussed for years, maybe we could make a documentation for the case, but we would have to understand the reasons why it is not implemented in a more comfortable way then.

To sum it up: Why when there’s a cache hit, it doesn’t just return the hit in the data return variable?

Intended outcome:

loading = true
data = undefined

// Cache hit!
loading = false
data = { ... }

Actual outcome:

loading = true
data = undefined

// Cache hit!
loading = false
data = undefined // Data was found, but data was not returned from cache

How to reproduce the issue:

const { data, loading } = useQuery(
	QUERY,
	{
		// If 'network-only' is used, it returns data correctly
		fetchPolicy: 'cache-and-network', 
	},
)

Versions npx: installed 1 in 0.807s

System: OS: Linux 5.7 Manjaro Linux Binaries: Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node Yarn: 1.22.4 - ~/.nvm/versions/node/v12.16.3/bin/yarn npm: 6.14.4 - ~/.nvm/versions/node/v12.16.3/bin/npm Browsers: Firefox: 81.0 npmPackages: @apollo/client: ^3.1.1 => 3.1.1 apollo-link-context: ^1.0.20 => 1.0.20 apollo-link-http: ^1.5.17 => 1.5.17

[jdalegonzalez]

@exapsy This is probably too late to help you but…

Whenever this happens to me, it’s always because a query that doesn’t request a field populates the cache and a later query asks for another field and it’s missing. The apollo client very unhelpfully drops the error on the ground even though it knows what field is missing. The gross way to figure it out is to put a breakpoint in @apollo/client/core/ObservableQuery.js around line 85 (search for diff = this.queryInfo.getDiff). You will see the return of void 0 - meaning no data for you. The diff, though, knows which fields are missing and could spit them out as console.warn - it just doesn’t. Open up the diff in the watch window and you’re set.

OR… less gross… set “returnPartialData” on your query options. Dump the output to console and compare what comes back with what you queried for. The missing fields will be the ones that are the problem. Another query will have hit the same object without asking for some of the fields.

[oeed]

I’d like also like to vouch that this needs a proper error message and description about what’s going on.

I already have a wrapper hook that catches this and alerts me, but even with that I just spend half a day figuring out what was actually causing the merge issue – had to slowly disable various components and parts of queries until I stumbled upon it.

Just a simple console.warn saying ‘this object couldn’t be merged because field X… etc’ would save many hours of headaches.