Derived Queries

[rstone770]

It would be really nice if there was some kind of recipe, hook, ect for derived queries. This is super useful when you have some derived data (similar to redux selectors) that you want but but also want to flow dependent query state down in order to propagate errors, use established react-query helpers, or simply to keep your async data related apis consistent.

const useFindLocationById = (locationId: string) => {
  const findAllLocations = useFindAllLocations(); // just hook that wraps some useQuery detail for fetching all locations.

  return useDerivedQuery([findAllLocations], ([allLocations]) => {
    const location = allLocations.find(l => l.id === locationId);

     if (location == null) {
       return Promise.reject(new Error(`Location ${locationId} not found.`));
     }

    return Promise.resolve(location); // it could return a promise here too.
  });
};

const SomeComponent = (props: { locationId: string }) => ReactElement | null => {
   const findLocationById = useFindLocationById(props.locationId);

   if (findLocationById.isSuccess) { ... } //ect
};

In the above example, we wait for allLocations to be success then we pass down the data into the derivation function which just simply returns a Promise as normal queries do. If an findAllLocations becomes faulted, we obviously expect the derived state to also be faulted.

Here is a multi query example.

const useFindUserPrimaryLocation = (userId: string) => {
   const findAllLocations = useFindAllLocations();
   const findUser = useFindUser(userId);
     
   return useDerivedQuery([findAllLocations, findUser], ([allLocations, user]) => {
      return Promise.resolve(allLocations.find(l => l.id ==== user.primaryLocationId));
   });
};

I have something locally that just finds the characteristic query and copy all values from it except remove and refetch which are more or less replaced with noops/identity since i couldn't decide if i should propagate those calls down too. There are also issues when deciding how to populate/aggregate certain meta fields like failureCount.

I think this is a common enough pattern that it should be offered by as first party solution.

[TkDodo]

If I’m not mistaken, you want the select option:

const useTodosQuery = (select) => useQuery(['todos'], fetchTodos, { select })
const useTodosCount = () => useTodosQuery((data) => data.length)
const useTodo = (id) => useTodosQuery((data) => data.find((todo) => todo.id === id))

see also: https://tkdodo.eu/blog/react-query-data-transformations

[rstone770]

Pretty much, except that the select works across N queries. So I guess more like query composition. I'm using this to build a more complex state graph from a couple simple queries.

…

On Thu, Apr 22, 2021, 10:29 PM Dominik Dorfmeister ***@***.***> wrote: If I’m not mistaken, you want the select option: const useTodosQuery = (select) => useQuery(['todos'], fetchTodos, { select }) const useTodosCount = () => useTodosQuery((data) => data.length) const useTodo = (id) => useTodosQuery((data) => data.find((todo) => todo.id === id)) see also: https://tkdodo.eu/blog/react-query-data-transformations — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2178 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5PZTTZDZ5RYYLNBHKO5ZLTKEAUTANCNFSM43NMRTUQ> .

[TkDodo]

useQueries might help

[rstone770]

Its not the same thing. What i want is something such as Promise.all that acts over query results so i can create derived data from multiple query results while still propagating state.

const useFindXByUserId = (id) => useQuery(['x', id], fetchUsers);
const useFindYByUserId = (id) => useQuery(['y', id]);

const useSomethingWithXAndY = (id) => 
  useDerivedQuery(
    ['x and y', id],
    [useFindXByUserId(id), useFindYByUserId(id)],
    ([x, y]) => {
       return Promise.resolve({});
    });

would be more or less.

const findXByUserId = (id) => Promise();
const findYByUserId = (id) => Promise();
const useSomethingWithXandY = (id) => {
   return Promise.all([findXByUserId(id), findYByUserId(id)])
      then(([x, y] => Promise.resolve());
};

The continuation then is only called ones all values are resolved and with the query results. It will also propagate a pending or rejected state depending on the promise states passed in as dependencies. Obviously queries arnt promises since values can resolve multiple times so it would be like a combine/map scenario over observerables.

[TkDodo]

I see. one of the problems is that it's hard to combine queries, as there are so many different ways to interpret it. would you want loading state as long as both queries are loading, or are we optimistic and are successful as soon as we have one successful query. same for error (do we show one error, two errors?). what you can do is something like this, but its manual:

const useDerivedQueries = (queries, combine) => {
  return {
    isLoading: queries.some(query => query.isLoading),
    error: queries.find(query => query.error),
    data: combine(queries.map(query => query.data)),
  }
}

because of the many different ways of how to combine queries, I don't see a generic way of achieving it 🤔

[rstone770]

Yeah. The semantics as you describe is the tricky part. For my own
implementation it's pretty much Promise.all so pretty pessimistic. If one
query is loading/idle/error, The resulting query just reflects it. if every
query is a success we are also a success. I was thinking that if I had the
query keys I could poke into the cache to find all the dependent queries
and use an observerable combine operater to listen to the queries directly.
The other tricky part is taking advantage of the query cache for all the
benefits that normal queries receive. Since they cache requires a query fn,
I haven't found a good way to hook into it for things like obviously
caching but also so you can use the standard query options like initialData.

As an aside, it'd be nice to have etag or something on a query result that
you can tie into useEffect to detect any querying changes. It could be just
like a number that increments with any query reducer churn. Currently it
looks like the actual query result can't be used an an effect dependency
because the result seems to be recreated on every render. So I've been
using a hashing scheme to detect changes in query states using update
times, flags and status.

If there isn't a good way of doing this generally, maybe we can have tools
to help do that kind of thing. Easier query change detection and including
the key on the query result would provide massive introspection power in
general.

[bzitzow]

This is a great question, and I found this thread searching: "ReactQuery +composition".

Composition is a fundamental (and powerful) design principle for managing complexity in software, and I would also find a reference for query composition valuable. I, too, looked at useQueries, however the use case described is for multiple dynamic queries, and the API is well suited for that.

I essentially have the same use case as @rstone770 , creating derived data from multiple query results (in different contexts), while still propagating state.

Would modeling something after Promise.all and Promise.allSettled be a bad idea?

Or how about returning a promise from useQuery (maybe a useQueryPromise() hook that behaves the same except the return result is the promise).

We would then be able to create an array of promises from multiple custom query hooks, and return that from a standard useQuery and use select to derive the data we need.

[TkDodo]

You can use queryClient.fetchQuery inside a queryFn of another query.

[non25]

This is really interesting.

I often have a case where one query depends on another.

E.g. one of them is called init, which contains a few labels to be joined by id

type Label = {
  name: string;
  color: Color; // color, union of strings
}

and the other one is called orders, that has field type_id. There are few labels, but the list of orders could be big, so we're saving backend's resources by not joining this redundant data for each request.

There are two ways which I end up using, each one of them is not ideal.

1. useOrders hook has useInit in it, and is using the data in queryFn. Similar to example above, this has huge drawback, whenever init updates, we won't get that derivation updated without redundantly refetching useOrders. And even then we'd have to trigger it somewhat manually if init ever gets refetched.
2. useInit and useOrders are wrapped in a separate hook, let's say useJoinedOrders, that makes a derivation in a useMemo. Downside is that every component will have it's own useMemo derivation, which is not de-duped, and also it will have long ugly list of dependencies.

What I thought about after searching for a while, is that we can make useJoinedOrders a third query, which will subscribe to them both outside of react-query and will re-populate ['orders', 'joined_list'] each time there's a change in one of them.

['orders', 'init']
['orders', 'list']
['orders', 'joined_list']

I really don't want derivations to happen in react land (context, components).

Is there a better way? 🤔