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

useQuery with fetchPolicy: 'standby' returns loading state as true when there is no loading happening #7564

Closed
Tracked by #8596
aweppc opened this issue Jan 11, 2021 · 3 comments
Assignees

Comments

@aweppc
Copy link

aweppc commented Jan 11, 2021

I have a component that draws a chart with some statistical data. There are 4 filters for that data. I have a useQuery hook that looks like this:

    const {
        data,
        loading,
        error,
        refetch,
    } = useQuery<ActivitiesQueryV2, ActivitiesQueryV2Variables>(
        ACTIVITIES_QUERY_V2,
        { variables, fetchPolicy: 'standby' }
    );

Variables for the query represent filters and are fed into component from parent component. I use 'standby' fetch policy due to the fact that we need to fetch data only when all filters are set and "Draw chart" button is pressed (which causes refetch to be called) and not on any change to any of the filters (due to performance reasons)

Intended outcome:
I expected the loading field of useQuery result to be true only during active refetch and to be false during initial render and consequent re-renders that shouldn't cause query fetching by themselves

Actual outcome:
useQuery returns result with loading set to true on initial render that stays true until refetch is called. Once refetch completes and component re-renders with new data, loading is set to false. Once the component re-renders again with different query variables - then the faulty behaviour reintroduces itself - data fetching is skipped, but loading is set to true once again

How to reproduce the issue:
https://codesandbox.io/s/loving-margulis-jy573
Here I've changed the following:

  • changed useQuery to use standby fetch policy
  • added a Fetch persons button to trigger refetch

You can see that initially component renders with Loading... instead of emptiness due to the issue. As soon as you click the Fetch persons button, everything will work as normal.
Haven't implemented the case with updating variables, because this is a part of another issue that was acknowledged in this commentary.

Versions
System:
OS: macOS Mojave 10.14.6
Binaries:
Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node
Yarn: 1.22.0 - /usr/local/bin/yarn
npm: 6.14.4 - ~/.nvm/versions/node/v12.16.3/bin/npm
Browsers:
Chrome: 87.0.4280.88
Firefox: 69.0.1
Safari: 14.0.1

tried on @apollo/client versions 3.2.5 and 3.3.6 (which appears to be in the latest tag at this moment)

@aweppc
Copy link
Author

aweppc commented Jan 11, 2021

tried to work around this issue by using networkStatus, but it's at NetworkStatus.loading value as well

@aweppc
Copy link
Author

aweppc commented Jan 11, 2021

Just in case anyone will bump into same issue and it's not resolved - here's the simplest (but dirtiest nevertheless) workaround that helped me

  • added onCompleted: () => setIsLoading(false) to useQuery options - handles first fetch
  • added setIsLoading(true) before a call to refetch(variables)
  • added .then(() => setIsLoading(false)) after refetch(variables) call, since it returns promise that resolves on refetch completion

Still, would like this issue to be taken care of, just to keep code clean of what I did here, when possible

@atrn0
Copy link

atrn0 commented Feb 21, 2021

we need to fetch data only when all filters are set and "Draw chart" button is pressed (which causes refetch to be called) and not on any change to any of the filters (due to performance reasons)

You can probably use useLazyQuery for this purpose.

https://www.apollographql.com/docs/react/data/queries/#executing-queries-manually

The useLazyQuery hook is perfect for executing queries in response to events other than component rendering.

@brainkim brainkim self-assigned this May 25, 2021
@brainkim brainkim mentioned this issue Aug 13, 2021
14 tasks
brainkim added a commit that referenced this issue Aug 13, 2021
brainkim added a commit that referenced this issue Aug 13, 2021
brainkim added a commit that referenced this issue Aug 16, 2021
brainkim added a commit that referenced this issue Aug 16, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants