using the data of one query to fetch the data for another

[alissaVrk]

the thing that I'm trying to achieve is:
we have query A - fetches some data.
and query B - it query function uses the data from query A (lets say by calling fetchQuery).

there are a few issues here:

1. if query A isn't used directly in react tree it's inactive, which means that it will be garbage collected and if I had query C using its data it would have to be fetched again.
2. query B won't refetch if query A changes

to solve (2) I can use cache onSuccess callback and invalidate query B - this is kinda nice cause I can maintain a static registration of dependencies.
but this won't solve (1)

QueryObserver should solve both, but there are a few problems here:

1. I don't know of a good place to unsubscribe- is there something called when a query becomes inactive? or when it becomes active?
2. the QueryObserver is a reference that I just don't have a good place to put.. the only instance I have outside of react is the queryClient. I think it would be nice if the observer would be part of it

in general, I think it could be nice if there was a way to declare dependencies between queries - say that query B is observing query A and should be invalidated whenever the data of query A is changed.

[TkDodo]

I'm not quite sure I follow your situation / problem completely.

Ad 1, you could just disable garbage collection for query A by setting a higher cacheTime. Yes, if you garbage collect it, and you run query B that needs query A, it will have to fetch query A first. But that's okay, as you can choose to not gc it.

Ad 2 if query B depends on queryA, the data it depends on should go to the query key, as per usual.

The dependent queries section in the docs shows that quite nicely, and I would just put the two things into a custom hook so that the GC issue doesn't even arise because as long as queryB is used (which uses query A, query A will also be used):

 const { data: user } = useQuery(['user', email], getUserByEmail)
 
 const userId = user?.id
 
 // Then get the user's projects
 const { isIdle, data: projects } = useQuery(
   ['projects', userId],
   getProjectsByUser,
   {
     // The query will not execute until the userId exists
     enabled: !!userId,
   }
 )

In this example, if email changes, the user will refetch to give us a new userId (queryA), which will then fire off the projects request for that new user, because user.id is part of the second queries' key (queryB).

[alissaVrk]

disabling the gc isn't really a good solution, I'd like it to be garbage collected when it isn't used anymore

about the custom hook, I'm trying to find a solution that doesn't involve react since I believe that the layer between the business logic / data fetching logic and react should be as thin as possible to avoid all code going into hooks - it encourages people to mix ui concerns with business logic ones.

I've found a way to do it manually, but it could be nice if this was part of the framework :)

const queryObservers: {[key: string]: {[key: string]: {observer: QueryObserver, unsubscribe: () => void}}} = {};

queryClient.getQueryCache().subscribe((event) => {
    if (!event) {
      console.log("WTF..?");
      return;
    }
    const observers = queryObservers[event.query.queryHash];
    if (event.type !== "observerRemoved" || event.query.isActive() || !observers) {
      return;
    }
    values(observers).forEach(observerInfo => {
      observerInfo.unsubscribe();
      observerInfo.observer.destroy();
    });
    delete queryObservers[event.query.queryHash];
  });

export function registerQueryDependency(from: QueryOptions, to: QueryKey) {
  if (!from.queryKey) {
    throw new Error();
  }
  queryObservers[hashQueryKey(to)] = queryObservers[hashQueryKey(to)] || {};
  const toEntry = queryObservers[hashQueryKey(to)];

  const observer = toEntry[hashQueryKey(from.queryKey)];
  if (!observer) {
    const newObserver = new QueryObserver(queryClient, from);
    const unsubscribe = newObserver.subscribe(() => {
      queryClient.invalidateQueries(to);
    });
    toEntry[hashQueryKey(from.queryKey)] = {
      observer: newObserver,
      unsubscribe
    };
  }
}

in general, I like this library very much so far and I think it could be very nice to decouple it from react so that other people could enjoy the caching layer :)

[TkDodo]

it encourages people to mix ui concerns with business logic ones.

I would disagree with that. hooks are the separation where the business logic should live, as markup lives in components. By extracting logic into custom hooks, you have a good separation between logic and markup.

QueryObserver is not really meant to be used if you are using react. It's part of the react-query agnostic core so that other frameworks (like svelte, vue or solid) can build bindings for their framework. If you use it directly, you will lose a bunch of the optimizations we do we do in useQuery that are specific to react, like batching, optimistic results, support for error boundaries or suspense, tracked queries for render optimizations and so on ...

[alissaVrk]

I do not intend to skip the hooks all together, just make them smaller.
the problem that I've seen in a few codebases with business logic in hooks is that you get mixed hooks that do everything - render stuff, navigate, do business logic calculations etc. so you have to read the hook code to know what are the potential side effects

since hooks have access to all the contexts and useEffect it is very hard to limit their functionality.
and you find yourself using useMemo and useCallback more than you'd like to so that new references won't be created all the time.