Select option for QueryClient.getQueryData or allow useQuery select without queryFn

[DanielOrtel]

I may be misunderstanding something here, but as far as I'm aware, select is only possible with useQuery, there isn't an option to do that when directly selecting from the cache. And I'm making a second assumption here, that the following code will trigger a rerender every time any part of the cached data changes, while select offers the possibility for partial subscription:

  const data = queryClient.getQueryData(queryKey);

If my two assumptions are correct, this presents a bit of a problem for me: I'm migrating away from Redux, and my current architecture relied heavily on partial store subscriptions, something I don't want to lose. I also have a standardised api, so I wrap useQuery, useInfiniteQuery, etc. within custom hooks, so that I can automate some functionality which I'd otherwise need to duplicate, like auth headers, auto generating query keys, etc.

I'd also like to have reusable selectors, since I know the exact structure of the api response, which is the same for every response. But here is where I run into a problem: I cannot rely on useQuery's select option most of the time, since it would require me to make unmaintainable prop drilling to relevant components.

• Consider a generic InfiniteList component, which gets the following props: resourcePath, pageSize, filter, order, include, etc. If I relied on useQuery'sselect option to build the selectors for partial data further down the tree(components which are memoized, so they don't rerender whenever a new page is fetched), I'd need to prop drill all query dependencies down and to reconstruct the useQuery at the top of the tree, which quickly becomes unmaintainable. And the way the component is, it requires hook-based subscription, I cannot just simply pass down the relevant data in the tree, since I would lose composability and extendability within the InfiniteList context.

This is not a pattern I'd like to move away from, however there is a simple solution: allow useQuery to act only as a selector, returning undefined when no queryFn was provided(I may be mistaken, but or add a select option to getQueryData. I may be mistaken, since the types don't require queryFn, but I get a runtime error of Missing queryFn if I don't provide one.

To clarify further, the current paradigm for writing selectors is this:

function useTodos(select) {
  return useQuery: {queryKey, queryFn: fetchTodos, select};
}

function useTodosLength() {
  return useTodos((data) => data.todos.length);
}

I'd like to be able to do this:

function useTodos() {
  return useQuery: {queryKey, queryFn: fetchTodos};
}

function useTodosLength() {
  return useQuery({queryKey, select: (data => data.todos.length)});
 // or
 return queryClient.getQueryData(queryKey, (data => data.todos.length));
}

[DanielOrtel]

Now that I think about it, useQuery without queryFn wouldn't work all that well, so queryClient.getQueryData selector should be it.

[TkDodo]

that the following code will trigger a rerender every time any part of the cached data changes

getQueryData is not reactive, it’s not a hook, so no, it won’t trigger any re-renders. It shouldn’t be used at all during rendering.

I'd need to prop drill all query dependencies down and to reconstruct the useQuery at the top of the tree, which quickly becomes unmaintainable.

This is a typical client state management problem. You have some filters / params / whatever that you need to have available everywhere in your app. If you don’t want prop drilling, I’d suggest putting them somewhere into a global client state manager like redux or zustand. Then, your custom useQuery hook becomes:

const useMyQuery = () => {
  const filters = useStore(store => store.filters)
  const params = useStore(store => store.params)

  return useQuery({
    queryKey: ['something', filters, params],
    queryFn: () => fetchSomething(filters, params)
  })
}

I’m going into this in my talk “Thinking in React Query”: https://tkdodo.eu/blog/thinking-in-react-query

[DanielOrtel]

getQueryData is not reactive, it’s not a hook, so no, it won’t trigger any re-renders. It shouldn’t be used at all during rendering.

yeah, actually I don't know why I didn't realise that, it seems pretty obvious in retrospect.

Regarding the other point with useQuery, I already read through the "thinking in react query", I'm aware of the current paradigm that is proposed by React Query, the problem I have is not of a state management problem(as an aside: I don't want to tie this component to a state management library, for many reasons), it's an architectural problem: the consumer of the InfiniteQuery is not the one defining the fetch function, so if they want to use a selector for the data, they'd need to redefine the fetch function every time, which they don't know about. This can lead to inconsistencies quite easily, which in turn requires me to expose the fetch query, which in turn leads to a lot of duplication, which again can lead to inconsistencies. Or alternatively, making the InfiniteQuery a "dumb" component, and requiring data to be passed down to it, which removes a lot of useful automations within the component.

The other problem is that with the paradigm of selecting from useMyQuery, I cannot define reusable hook selectors based on querykey. By having a useSelector({queryKey, select}), or just simply allowing useQuery({queryKey, select}) to just fetch from cache, I can just expose auseRelationshipSelector(queryKey) and call it a day.

I may be missing something here, but I don't understand why a useSelector wouldn't be possible:

• from a design perspective, an InfiniteDataItem component does not need to define the fetch function for the entire InfiniteData context. It just needs to select a specific item from a specific row. It doesn't need the context on what filters, orders, pagination were applied to to fetch the data, it just needs to know which query key it wants to select from.
• And from a code complexity perspective: useQuery already does this to an extent: it fetches from cache in case it is not stale. useQuery({queryKey}) actually kind of already works, it returns the correct cache values, except it will fail in certain scenarios, and I can't put my finger on exactly what it is, though I suspect it's when it is stale and the useQuery({queryKey}) is called before useQuery({queryKey, queryFn}).
• the one potential downside of a useSelector pattern, is that it could potentially return stale data, though I don't see that as a serious issue

Again, I may be missing something, since useQuery with only the queryKey already kind of works, it just errors out when stale data is met.

[TkDodo]

the consumer of the InfiniteQuery is not the one defining the fetch function, so if they want to use a selector for the data, they'd need to redefine the fetch function every time, which they don't know about. This can lead to inconsistencies quite easily, which in turn requires me to expose the fetch query, which in turn leads to a lot of duplication, which again can lead to inconsistencies.

the idea is to abstract that away with queryOptions or custom hooks.

I may be missing something here, but I don't understand why a useSelector wouldn't be possible

The idea is that components are self sustaining. useQuery ideally reads from the cache and potentially re-evaluates data, but if data isn’t there, it will trigger the initial fetch. That makes it easy to re-use this component in other places. With just a “select this data from that key” kind of hook, if there is no data in the cache, you will just get undefined back and your component will never see data unless you explicitly fetch it somewhere else. This creates an implicit coupling between components, where your component with useSelector might work as expected if a different component was rendered previously (that fetched data), while it might not work if rendered in a different place where data was never fetched.

[DanielOrtel]

Sorry for the late reply, I've been busy with another project that doesn't involve Tanstack stack.

I suppose it's a matter of philosophy at this point. I don't see the issue with the implicit coupling, because the results are readily obvious in case a mistake happens. I generally prefer building up plug-and-play systems, where a component can automatically subscribe to a given "context"(in this case it would be the specific query), which in this paradigm is more difficult to achieve, albeit doable somewhat.