Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetchPolicy: 'standby' returns loading state as true before HTTP request start #12122

Open
viico opened this issue Nov 13, 2024 · 1 comment
Open

Comments

@viico
Copy link

viico commented Nov 13, 2024

Issue Description

We want to use the standby fetch policy to call our API only when we use refetch.

The problem is that the loading field of ApolloQueryResult is true before any HTTP call. The issue was discussed here : #7564, but the solution is to use useLazyQuery which is not available for apollo-angular.

I don't understand why the field loading is initialized to true if there is no loading yet ?

Link to Reproduction

https://github.com/viico/apollo-fetch-policy-standby-loading

Reproduction Steps

We create a repo for reproduction here : https://github.com/viico/apollo-fetch-policy-standby-loading.

When you start the angular application you will see that there is no HTTP request before we refetch (that's ok) but the loading field is true anyway.

image

@apollo/client version

3.0.0

@phryneas
Copy link
Member

phryneas commented Nov 18, 2024

As far as I understand it, standby was added at some point to enable the skip use case of useQuery, but no additional networkStatus was added for it - instead, the networkStatus with "no data and no error" was used for it - loading.

The React hooks work around that outside the core as you can see here:

const skipStandbyResult = maybeDeepFreeze({
loading: false,
data: void 0 as any,
error: void 0,
networkStatus: NetworkStatus.ready,
});

This is something that - while confusing - could break a lot of apps if we were to change it. I'll bring it up internally, but short-term I have little hope that we can change it.

Your best bet is probably to work around it in a similar fashion for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants