Apollo-client: loading flag should be true on initial network request of cache-first policy

Created on 13 Oct 2017  路  9Comments  路  Source: apollographql/apollo-client

Intended outcome:
Using the default 'cache-first' fetchPolicy, the client will need to load data from the network since the cache is empty initially. In order to display loading indicators, I need to be able to distinguish a network response from a cache response via the loading flag.

Actual outcome:
All responses using the cache-first policy have loading set to false. Hence no distinction is possible.

How to reproduce the issue:
Create a query with 'cache-first' fetchPolicy and inspect the loading prop of the response object.

Version

Most helpful comment

The docs at https://www.apollographql.com/docs/angular/basics/queries.html#basics state "The observable will only emit once when the query is complete, and loading will be set to false unless you set the watchQuery parameters notifyOnNetworkStatusChange or returnPartialData to true.", but I've found that even when setting notifyOnNetworkStatusChange to true, it does not. Also, the property returnPartialData doesn't exist. Using apollo-client 2.4.2. Setting fetchPolicy to cache-and-network made it work. But as this issue states, it should now. :/

I'm having exactly the same issue on 2.4.2 and could only get it to work using cache-and-network too.

All 9 comments

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

@alexthewilde can you see if this is still an issue for you with the latest version?

@alexthewilde I am unable to get the loading prop to come through at all on react-apollo 2.0.0 or 2.0.1. Here is a good example of the loading prop never changing, even though there is a network request happening:

https://github.com/zeit/next.js/tree/master/examples/with-apollo

New props aren't passed to the component until the data is actually loaded (e.g., the loading prop never comes through as true ). Does anyone have a working example of this pattern? Would think loading animations would be much easier relying on this prop vs. something custom on the component.

I was surprised when I switched from cache-first to cache-and-network that watchQuery initially emits with {data: undefined, loading: true} since cache-first never omitted loading: true. I agree that we should make them consistent.

I think I just spent several hours trying to figure out why loading was false even though I was seeing network requests. Wow. Thanks @ravishivt

I have a related fix pending for this so that no-cache also reports loading: true status when it does fetching. I think it may also resolve an issue where if you used client.query() with certain fetch policies, they would resolve with loading: true and no data.

https://github.com/kamranayub/apollo-client/commit/05b0f9033d47b545fee0e3ca665fab5549c8f379

This issue should now be resolved. If anyone is still running into this, please let us know. Thanks!

The docs at https://www.apollographql.com/docs/angular/basics/queries.html#basics state "The observable will only emit once when the query is complete, and loading will be set to false unless you set the watchQuery parameters notifyOnNetworkStatusChange or returnPartialData to true.", but I've found that even when setting notifyOnNetworkStatusChange to true, it does not. Also, the property returnPartialData doesn't exist. Using apollo-client 2.4.2. Setting fetchPolicy to cache-and-network made it work. But as this issue states, it should now. :/

The docs at https://www.apollographql.com/docs/angular/basics/queries.html#basics state "The observable will only emit once when the query is complete, and loading will be set to false unless you set the watchQuery parameters notifyOnNetworkStatusChange or returnPartialData to true.", but I've found that even when setting notifyOnNetworkStatusChange to true, it does not. Also, the property returnPartialData doesn't exist. Using apollo-client 2.4.2. Setting fetchPolicy to cache-and-network made it work. But as this issue states, it should now. :/

I'm having exactly the same issue on 2.4.2 and could only get it to work using cache-and-network too.

Was this page helpful?
0 / 5 - 0 ratings