What is the best (or alternate) ways to fetch the server data from a child component when the parent component hits an api that returns all the data that we need?

[dannynhois]

Should I be using useQuery for all children components or queryClient.getQueryData? My fear is if i use useQuery in the children component I may be potentially adding an unnecessary additional request, but if I'm wrong then I'm adding complexity for no reason. For example the layout is like this:

<Parent> // useQuery to fetch data here as data returned is shared between Child1 and Child2. 
  <Child1> //data from <Parent> is passed through to child components (A,B,C, etc) - no data is needed so nothing here
    <Child1A> // uses getQueryData here - only propA from <Parent> api call 
    <Child1B> // uses getQueryData here - uses only propB from <Parent> api call 
    <Child1C> // etc
  <Child2> // some data currently passed as a prop

What I've done is put the useQuery at the and then for any children components, I use the queryClient.getQueryData. I've created a few wrapper functions so I have a consistent way to grab the correct key based on url path.

useQueryCurrentGridViewlModel - is basically useQuery with the key already returned
useDataCurrentGridViewModel - is basically queryClient.getClientData with the key returned;

import { useProjectContext } from "@shared/context/ProjectContext";
import { useQuery, useQueryClient } from "react-query";
import { QueryKey } from "react-query/types/";
import { useLocation } from "react-router-dom";

export function useGetQueryKeyForCurrentView(): QueryKey {
    const location = useLocation();
    const projectInfo = useProjectContext();
    const path = location.pathname.toLowerCase();
    const projectNo = projectInfo.ProjectNo;
    const queryKey = [path,{projectNo}] //https://react-query.tanstack.com/guides/query-keys
    return queryKey;
}

export default function useQueryCurrentGridViewlModel<T>(url:string) {
    const queryKey = useGetQueryKeyForCurrentView();
    const queryFn = () => fetch(url).then(res => res.json());
    const {isLoading,isError,data, isFetching, error} = useQuery<T>(queryKey,queryFn);
    return {isLoading,isError,data, isFetching, error, queryKey}
}

export function useDataCurrentGridViewModel<T>() : T {
    const queryClient = useQueryClient();
    const queryKey = useGetQueryKeyForCurrentView()
    const data = queryClient.getQueryData<T>(queryKey)
    if(data === undefined)
        throw Error("useDataCurrentGridViewModel data is undefined");
    return data;
}

export function useReloadGrid() {
    const queryClient = useQueryClient();
    const queryKey = useGetQueryKeyForCurrentView();
    return async () => {
        await queryClient.refetchQueries(queryKey);
    }
}

[TkDodo]

what I don't like about queryClient.getQueryData is two things:

• it doesn't create a subscription - it only retrieves the data from the cache if it is rendered (for whatever reason), but it doesn't render per se when the underlying data changes. Now this might not be a problem in this case, but if you re-use your component or change the structure where <Child1A> is not rendered under <Parent> anymore - it will not work.
• basically, similar to the first point: It's unexpected that the component will not "work" anymore if it's rendered as a child of another component. components are not meant to work only if put in a specific order (leaving our <Providers> here on purpose :)) - they are meant to be largely independent / dependent on their props and state.

---

there are a couple of approaches:

1. just pass the data down as props. There's no shame in that, it's the most explicit and easy thing to do.
2. after reading from react-query, put the data in a state manager like zustand or a distribution system like context to access it further down the tree (I don't really like that approach, because it is mostly unnecessary and worse than point 3)
3. just call useQuery wherever you need the data. react-query will de-dupe request that are going out at the same time. since you mount the children after you have already fetched data, consider setting a small staleTime (5000 maybe) so that the child components will not immediately re-fetch. That's what staleTime is for. also, if you need further "render optimizations", you can narrow your subscription with the select prop. This reads a lot like useSelector from redux if you extract it to a custom hook, e.g.:

const useTodos = (select) => useQuery(
  'todos',
  () => fetchTodos(),
  { select, staleTime: 5000 }
)

// in parent:

`useTodos()` // will just give me all todos

// in Child1A

`useTodos(todos => todos.propA)` // will just subscribe me to propA

now Child1A will only re-render by itself if propA changes. in your case, this seems largely irrelevant, because your whole tree will likely re-render if <Parent> re-renders. But it also reads nice, is easy to grasp and there is no complexity whatsoever. Also, if you use Child1A somewhere else, it.just.works.

[tannerlinsley]

Not sure how much it helps in this situation, but you can also observe queries:

https://react-query.tanstack.com/reference/QueryObserver

[ghost]

Here is useQueryObserver (which nobody should use! See the following comment...)

export function useQueryObserver(queryKey, options) {
  const queryClient = useQueryClient();
  const [result, setResult] = React.useState(undefined);
  const observer = React.useMemo(
    () => new QueryObserver(queryClient, { queryKey, ...options }),
    [queryClient, queryKey],
  );
  React.useEffect(() => {
    const unsubscribe = observer.subscribe((result) => {
      setResult(result);
    });
    return unsubscribe;
  });
  return result;
}

[bertho-zero]

The previous data is however kept in the child component if I remove the search part of the queryKey and use a useEffect to manually refetch.

https://codesandbox.io/s/zen-chatterjee-qivdsj?file=/src/index.js

[TkDodo]

it's not previous data that is kept, it's just "the" data that is in the cache. With that approach, you cannot cache results dependent on the search. For example, if you search for a, then b and then a again, you would instantly get the cached result from a - not the previous results from b. With only a static key, there would only be one cache, so you would get b until a is loaded again, which is worse.

[bertho-zero]

I understand, thank you. So I can't use custom hooks in this situation without having to pass the result via props through my whole tree.
There is no way to retrieve the previous data from a similar query with queryClient?

[TkDodo]

if you know the previous search, you can get the data with queryClient.setQueryData

[bertho-zero]

But it's not ideal according to your comment

Can we imagine something like useQueryData or an option that allows previousData to be persisted across hooks with the same queryKey like data?

[ghost]

OK thanks again - I saw your answer here and combined with the question, it led me to believe that I should be using QueryObserver to observe an already-created query.

I suppose that I could just replace new QueryObserver with useQuery in that answer and the result would be what I want.

Still trying to decide, but I'm heavily leaning towards RTK-Query at this time because they have a hook useQueryState which will let me easily observe a query without refetching anything or writing custom hooks where as react-query will have me wrapping useQuery to create various observations of the query.

[TkDodo]

It's a bit a different approach. With react-query, you control data fetching with staleTime. This is a classic caching approach that http has been doing forever, similar to cache-control: max-age=60, which tells the browser to cache data for 60 seconds. Requests going out in that time will not hit the backend, only the browser cache. That's pretty much what staleTime does in RQ.

RTK-Query seems to go a different approach with a separate useQueryState hook, which is also fine. It just means that if you use this component in a situation when no data is in the cache, it will just stay loading forever? It makes your component dependent on redux state while still being not able to live on its own. Kind of the worst of both worlds, or do I have this completely wrong 🤔

It seems that RTK-Query also has something similar by passing a number to refetchOnMountOrArgChange, but not for refetchOnFocus

[ghost]

Having the component be dependent on redux state is not a problem for me. The way I see it, every data-bound component is going to be dependent on something whether it's react-query, rtk-query, redux thunk action/selector, a HOC or just plain props passed from the parent and some degree setup is involved with each of those.

On the other hand, looking at the react-query examples I see that setting up a react-query environment is quite a bit simpler than setting up a redux store. So, with that in mind perhaps I'll give react-query another look and see if I can't make it work for me.