hook for consuming other query aka useQuery without queryFn

[brumm]

Hey Tanner,

Suppose I have one useInfiniteQuery hook, and I want to display the resulting data in multiple sibling components. Or in a different case, my component is rendering a child component which fetches data via useQuery, but the parent needs to monitor the child's status

What I need is a way to read a query from the cache in a reactive way. This could be done by making fetchFn optional, and allowing a component to subscribe to a query without having to provide the fetcher for it.

Currently I'm using this as a first attempt:

export const useOtherQuery = queryKey => {
  const [state, setState] = React.useState({})
  const query = queryCache.getQuery(queryKey)

  React.useEffect(
    () =>
      query.subscribe({
        id: Math.random()
          .toString(32)
          .slice(2),
        onStateUpdate: setState,
      }),
    []
  )

  return {
    status: query.state.status,
    error: query.state.error,
    isFetching: query.state.isFetching,
    data: query.state.data,
  }
}

Doe you see any concerns with this? Is this something the library could offer by default?

[wolverineks]

for both cases i would look into raising the query into a context

const PostsProvider = () => (
  <PostsContext.Provider value={useInfiniteQuery(...)}>
    <PostsSideEffects />
    <Children />
  </PostsContext.Provider>
)

const PostsSideEffects = () => {
  const posts = usePosts()

    React.useEffect(() => {
    if (posts.status === whatever) {
      doTheThing()
    }
  }, [posts.status])

  return null
}

[wtanna]

I had to find a solution for something similar. I've seen a few discussions in here regarding using the queryCache as it's own store, but it's not really clear what the best pattern is for notifying other components of a query status or data change.

#489
#438

Like @wolverineks suggests, I ended up using React Context and it's been alright. Here is a real basic example that I cooked up to get something working

https://codesandbox.io/s/subscribe-70q5e

It has a "deeply nested child" that is creating an item. The AppHeader component is the highest level component in my app that needs to render a status when an item is being created as it could take some amount of time. Additionally, I have a button in the sandbox to mount/unmount the component that initially called the create mutation as it's possible for the user to go to different parts of the app, and therefore they may never return to the initial component that called the create.

All the magic happens in the use-items.js hook file

import React from "react";
import { useQuery, useMutation, queryCache } from "react-query";

import * as api from "./distractions/api";

function useItemsFromAPI() {
  const { data: items, status: findStatus, isFetching } = useQuery(
    ["items"],
    api.fetchItems
  );

  const [createItem, { status: createStatus }] = useMutation(api.createItem, {
    onSuccess: (item) =>
      queryCache.setQueryData("items", (previousItems) => [
        ...previousItems,
        item
      ])
  });

  return { items, findStatus, createStatus, isFetching, createItem };
}

const ItemContext = React.createContext();

function ItemProvider({ children }) {
  return (
    <ItemContext.Provider value={useItemsFromAPI()}>
      {children}
    </ItemContext.Provider>
  );
}

function useItems() {
  const context = React.useContext(ItemContext);

  if (context === undefined) {
    throw new Error("useItems must be used within ItemProvider");
  }

  return context;
}

export { useItems, ItemProvider };

but the useItemsFromAPI is doing a lot and isn't exactly how I am doing things in my app. I only brought the useQuery and useMutation together as it was easier to demo and set the queryCache as I can't invalidate to refetch data, as that is also an expensive query for my use case.

Finally, the app I am working on is a lot more complex then my above sandbox. It has to leverage using useReducer as well, in which case I'm using the same pattern as Kent as written up here:

https://kentcdodds.com/blog/how-to-use-react-context-effectively

[phatmann]

For my use case I get message add/remove "events", yet a client just wants to see a list of messages. I use a "messages" query that mounts the events query and then updates its cache as events come during the rendering phase. The messages query function does nothing. This neatly takes care of the observer pattern and feels semantically correct. The observers of the messages query have no idea about the underlying architecture, which is great.

I would like to see explicit support for these types of "dependent" queries. All I need is a way to omit the query function. Right now if you do that you get a warning message.

[TkDodo]

if you don't have a queryFn, what do you need react-query for? E.g. you can't invalidate / refetch those queries... It looks like what you want is some sort of global state management where you just push your events to when they come in so that you can read them everywhere in your app. Zustand is great, but also useState + context might just be enough here, unless I misunderstood your example ....

[phatmann]

Here are the reasons I am using a query without a query function:

• I am using persistQueryClient to save all of my cached data. Therefore it is very convenient to also have my messages in the cache.
• I want the consumers of the messages data to interact with this data as if it came from a normal query. I could indeed use a context and useState to simulate the query API...or I could just use the query API 😄

[phatmann]

I decided queries without query functions are indeed an anti-pattern. I rewrote my code to use a single messages cache instead of one cache for message events and another cache for messages. The query function for the messages cache does something interesting. First it fetches new message events from the server. Then it gets the existing messages via getQueryData. Finally it goes through each events and transforms the existing messages by adding a new message or removing an existing message. This transformed list of messages gets returned from the query function. Works very well and is simpler to understand and manage. So thanks for pushing me in the right direction @TkDodo!