Is there any need to use Context API with React Query?

[cmacdonnacha]

Hey there,

I have seen some patterns lately where folks seem to use the Context API to pass data retrieved from React Query down to child components. Personally I tend to use useQuery inside of a custom hook, and use that in each child component instead.

From reading this stack overflow answer, it sounds like my approach is preferred, but I was wondering if there is any case whatsoever where using Context API along with React Query would make more sense? The only thing I can think of is perhaps if the user changes some filters (like car color) in a top level component, you may want an easier way to pass that down instead of prop drilling, and then use that filter as a key inside useQuery to perform a refetch?

Are there any other specific reasons why custom hooks would be preferred over Context API? Would it prevent more re-renders? Just looking to get some opinions. It might simply just be a pattern preference.

Thanks!

[clicktodev]

I personally only use the Context API to manage layout state and sometimes form state if the forms are big and complex.
React Query handles all of my server state and I don't have to worry about managing it. And yes, wrapping queries and mutations in custom hooks is imo the preferred approach.
I highly recommend this talk if you haven't seen it yet.

[TkDodo]

I have seen some patterns lately where folks seem to use the Context API to pass data retrieved from React Query down to child components.
if there is any case whatsoever where using Context API along with React Query would make more sense?

I might be biased since I wrote the StackOverflow answer, so I usually prefer to call the custom useQuery hook whenever I need to. It does create more observers and timers, so if you have like 1000 of them, there have been reports of performance hits (e.g. on a 6x slowdown in chrome).

Putting data from react-query into the context api is not the worst idea though - it's just a decoupling of some sorts, just like prop drilling. consider:

- ParentA <--- calls useQuery
  - ChildB (receives `data` as prop)
    - ChildN (`data` drilled down until here)

in this case, you can either just call useQuery in ChildN, or prop drill, or have ParentA create a context where you put the data and have ChildN read from the context.
This is probably most useful if you want to additionally use ChildN in a place where the same data is not coming from a query - maybe you read it directly from localStorage on that page or something. In that case, you have a different ParentX that can just provide the context and ChildN will just read read.

I think this is a valid use-case, and it's also not the usual state-syncing anti-pattern, as the single source of truth is still the query itself (or whatever other source we have for that context). All background updates of RQ will also still work because the Parent will re-render, and the child will get that update.

One thing to keep in mind is to memoize the children to the Provider to avoid unnecessarily re-rendering the whole tree, and you also cannot do fine grained subscriptions like you can do with e.g. the select option on useQuery. Tradeoffs everywhere :)

[shamilovtim]

I have seen some patterns lately where folks seem to use the Context API to pass data retrieved from React Query down to child components.
if there is any case whatsoever where using Context API along with React Query would make more sense?

I might be biased since I wrote the StackOverflow answer, so I usually prefer to call the custom useQuery hook whenever I need to. It does create more observers and timers, so if you have like 1000 of them, there have been reports of performance hits (e.g. on a 6x slowdown in chrome).

Putting data from react-query into the context api is not the worst idea though - it's just a decoupling of some sorts, just like prop drilling. consider:

- ParentA <--- calls useQuery
  - ChildB (receives `data` as prop)
    - ChildN (`data` drilled down until here)

in this case, you can either just call useQuery in ChildN, or prop drill, or have ParentA create a context where you put the data and have ChildN read from the context. This is probably most useful if you want to additionally use ChildN in a place where the same data is not coming from a query - maybe you read it directly from localStorage on that page or something. In that case, you have a different ParentX that can just provide the context and ChildN will just read read.

I think this is a valid use-case, and it's also not the usual state-syncing anti-pattern, as the single source of truth is still the query itself (or whatever other source we have for that context). All background updates of RQ will also still work because the Parent will re-render, and the child will get that update.

One thing to keep in mind is to memoize the children to the Provider to avoid unnecessarily re-rendering the whole tree, and you also cannot do fine grained subscriptions like you can do with e.g. the select option on useQuery. Tradeoffs everywhere :)

Could you point to any resources which outline in what instances React Query (how many mounts of useQuery) slows down an application? We use React Native and in some instances we might have large lists that useQuery hundreds/thousands of time. I'm curious if in the case of large lists we should be passing the query data as param rather than mounting useQuery over and over again. I'm also curious if anyone has compared the cost of query data as a prop to a component compared to the cost of useQuery inside that component. Should the React Query project and its users / contributors be thinking of breaking ground on this research and adding it to the docs?

Here is another design pattern we use which I've been targeting for a refactor:

useB depends on useA
useC depends on useA

Instead of:

parent = () => {
   useA();
   useB();
   useC();
}

This:

// only one instance of useA is needed for all of the different dependent hooks
parent = () => {
  {aData} = useA();
  {bData} = useB(aData);
  {cData} = useC(aData);
}

Have you encountered these tradeoffs yet? I've worked with devs who considered remounting dependent hooks inside other hooks as the ideal approach because it was decoupled. My problem with that this is not decoupled at all. It is a different form of coupling. And from what I can tell, performance might suffer.

[shamilovtim]

Would you have any feedback on this @TkDodo?

[TkDodo]

Could you point to any resources which outline in what instances React Query (how many mounts of useQuery) slows down an application?

nope, it really depends.

Should the React Query project and its users / contributors be thinking of breaking ground on this research and adding it to the docs?

if you have some research, we can add it, but every measuring is largely depending on environment I guess?

Have you encountered these tradeoffs yet? I've worked with devs who considered remounting dependent hooks inside other hooks as the ideal approach because it was decoupled. My problem with that this is not decoupled at all. It is a different form of coupling. And from what I can tell, performance might suffer.

you can do both things really. For example, if you have a query that needs an id:

const myQuery = (id) => useQuery(...)

and use it with: useMyQuery(5)

if id comes from the url, you will have something like:

const { id } = useParams()
const { data } = useMyQuery(id)

if id always comes from the url, you can add the useParams call into your hook to make it more "transparent". I agree that this is not less coupled.

• passing the id to a hook is like passing a prop to a component.
• using useParams directly in the hook is like using useParams directly in a component
• you can also take the value from useParams, stick it in a custom IdContext and then let the hook read from there. decoupled from the url, still has something it needs for dependency injection.

where you draw the line is up to you :)