Getting loading status of queryClient.fetchQuery

[ryanmk54]

I currently use queryClient.fetchQuery to fetch a query and store the data in a reducer. I would like to get the loading status of fetchQuery. useQuery has a loading status, but there isn't a promise function like fetchQuery returned from useQuery. There is refetch, but that will discard old data. There is onSuccess, but that will only be called when there is new data. fetchQuery returns data in every case and loads data from cache.

I am thinking of a couple of options:

1. I could use a useQuery to store the loading state and fetchQuery to get the data and dispatch it into the reducer state.
2. I could use a state to store the loading state and fetchQuery to get the data and dispatch it into the reducer state.

Is there part of the library I've overlooked that will show me the loading status of a query. Option 1 seems best, because it seems redundant to create a state, when react-query already stores the loading state. Is it overkill to use the useQuery hook just to get the loading status?

[TkDodo]

I currently use queryClient.fetchQuery to fetch a query and store the data in a reducer.

I think you are missing the point of react-query a bit if you use it to fetch data and then store it in a state manager like redux or useReducer. react-query is the state manager!

The idea is that you just call useQuery wherever you need to, and it will give you back { data, error, isLoading } (among other things). You can write a custom hook if you want, but the idea is to use the data returned by useQuery so that you don't need another state-manager. useQuery will also fetch the data if it does not yet exist, so queryClient.fetchQuery is rarely needed (I have never used it).

Please have a look at the various examples we have, e.g. https://react-query.tanstack.com/examples/basic

[ryanmk54]

The reason I was storing the query data inside the reducer state is because part of the state is dependent on the query data. I was trying to keep my reducer separate from the body of my function component to make it more pure. The more I think about it, the more it seems like it would work better if I put my reducer inside the body of my function component. Is it considered bad practice to have my reducer inside the body of the function component so state updates can depend on query data and function props?

[ryanmk54]

Another reason that I was storing state is that I am fetching a default price, but also allowing the price to be overridden on a case-by-case basis. Overriding the price once would not override the default. Would it be best to use useQuery for this case or fetchQuery with a loading state?

[TkDodo]

Is it considered bad practice to have my reducer inside the body of the function component

No, this is fine I think, because it means you can closure over props.

Would it be best to use useQuery for this case or fetchQuery with a loading state?

I don't think I understand that use-case, sorry. I have always done useQuery for everything and there hasn't been a single case that I couldn't solve with the flexibility it provides. Feel free to create a codesandbox, then I can take a closer look if you want.

[ryanmk54]

Thanks Here is a codesandbox with my use case. I want the default price to be cached, but they should still be able to set the price to whatever they want.

[TkDodo]

Cool. Incidentally, I have written about this exact use case in my blog: https://tkdodo.eu/blog/practical-react-query :)
The idea is to take the data returned from useQuery and use it as a fallback to calculate the local state, which will take precedence as soon as the user has made some input. I've refactored your example to this approach: https://codesandbox.io/s/wandering-dust-yzpbf?file=/src/App.js

You will instantly benefit from background updates, (which you can further tweak to disable if you have local state already), and the loading spinner will not be shown if data already exists in the cache.

I would suggest to use the ReactQueryDevtools - they help tremendously when using useQuery.

[ryanmk54]

Awesome! That should work. Thank you!

[shipstar]

I have a similar question - new to GitHub Discussions and not sure what the etiquette is about creating a new thread vs commenting. Happy to move if needed. :)

For easy of testing and Storybooking, I think I want to try separating container and presentational components. I have a presentational SearchForm that manages its own state (query, sortBy, etc), then calls a props.search({ query, sortBy }) function when the user clicks submit.

I don't have access to the state in the container component (ConnectedSearch), so I can't useQuery directly and decided to useQueryClient instead with fetchQuery. Everything works, including the cache (which was my first real "OMG YES" moment with react-query).

Similar to Ryan, I'd love to be able to show a loading indicate while fetchQuery runs. I think I could do it myself with a simple useState(loading) hook, but that's kind of a bummer since I assume react-query is tracking this internally anyway.

It seems like I have 2 options:

1. Move state into the container component, switch to useQuery with enabled: false, then have a useState(searching) hook that I set to true when the user clicks the "Search" button to enable the query
2. Track loading state myself in the container

Seems like either way I might need to track one additional piece of state, either to enable the query or to track loading status.

Does that seem about right? Or am I missing something?

I think I'm starting to get the "zen" of react-query, but wanted to check my assumptions here. Thanks!

---

Small TypeScript excerpt to illustrate:

const ConnectedSearch = () => {
  // Option 1: Lift state here from child and useQuery(..., { enabled: isSearching })
  const [filters, setFilters] = useState<Filters>({})
  const queryClient = useQueryClient()

  const search = async ({ query, sortBy }) => {
    // Option 2: `setIsLoading(true)` here, then `setIsLoading(false)` after the query returns
    //
    // I wish this returned `{ isLoading, data }`, but maybe I'm missing something
    // And maybe I really wish there was a `useLazyQuery` hook since I would need
    // to use loading state outside this block anyway
    const data = await queryClient.fetchQuery(
      ["users", { query, sortBy }],
      () => api.getUsers({ query, sortBy })
    )
  }

  return <SearchBar search={search} />
}

const SearchBar = ({ search }) => {
  const [query, setQuery] = useState("")
  const [sortBy, setSortBy] = useState<SortOrder>(SortOrder.availability)

  const handleSubmit = (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault()
    search({ query, sortBy })
  }

  return <form onSubmit={handleSubmit}>...</form>
}

[TkDodo]

For easy of testing and Storybooking, I think I want to try separating container and presentational components.

I don't think this is necessary (anymore). You can use things like mock service worker (https://mswjs.io/) to mock out api requests, even in storybook or in tests. I would just do useQuery wherever I need it :)

With search and filter parameters, it is best to put them in the query key so that react-query will refetch automatically for you whenever the key changes. Yes, this means storing that information somewhere else (can be useState, can also be the url / router).

So even if you want to keep the separation between ConnectedSearch and SearchBar, in ConnectedSearch, you would do useQuery instead of useQueryClient:

const [filters, setFilters] = useState<Filters>()
const queryInfo = useQuery(['myKey', filters], () => getUsers(filters), { enabled: Boolean(filters) })

return <SearchBar search={setFilters} />

in the onSubmit of the form, you would just set the filters via setFilters (passed as search here), which would trigger the search. As you can see in the example code above, I have disabled the query as long as there are no filters set.

[shipstar]

I think I would also have to lift query and sortBy in my example into the container since they are part of the key as well. (I actually wanted filters in the child too - whoops!) Sounds like I've identified the tradeoffs and options correctly, though, and just need to decide which path I prefer.

I've experienced some pain on another project around having to mock out react-router and Apollo just to test simple components that incidentally do routing or look up one value. Like the old OO programming joke, it's like I want to render a banana and I have to bring the gorilla and the whole jungle along with it. :) I hadn't seen MSW, though, so maybe something like that would change my mind. I'll have to keep exploring.

Thanks for the detailed response! (And all of your other detailed responses about react-query. It's definitely helped me go from zero to beginner very quickly!)