blog/react-query-and-react-context

[giscus[bot]]

blog/react-query-and-react-context

Can it make sense to combine React Query with React Context ? Yes, sometimes ...

https://tkdodo.eu/blog/react-query-and-react-context#inject-comments

[jomefavourite]

Thanks for always keeping us updated on how to make good decisions when using React Query.

[Arcades2]

So cool as always ! Thx

[mk-nickyang]

Thanks for another great article!

I think Context is also a good solution when we have multiple useQuery instances mounted in different render cycles, and we only want the parent query to do the fetch job, the rest of query instances should just be reading from the state.

Like in the example below, TQ cannot deduplicate network fetches because Child components are conditionally rendered

const Child1 = () => {
    const { data } = useQuery();
    return ...
}

const Child2 = () => {
    const { data } = useQuery();
    return ...
}

const ParentScreen = () => {
    const { isLoading, isError } = useQuery(...);

    if (isLoading) return <LoadingView />

    if (isError) return <ErrorView />

    return (
        <>
            <Child1 />
            <Child2 />
        </>
    )
}

But with Context, we can avoid having duplicate network requests + props drilling, and Typescript will be pleased.

The only downside I can think of is, if we have select for some useQuery instances, there is no out-of-box way for Context to do partial subscribe (unless we use lib like use-context-selector).

Just wondering in this case, do you think if Context is still a better approach OR just setting a staleTime as you mentioned here?

[TkDodo]

if you just want to avoid the refetch because a new component mounted, setting staleTime is usually enough.

[p6l-richard]

Good write up (as usual).

Hard to think of any other use case than authentication or RBAC.

The “drawback” becomes a feature in these instances:
Blocking unnecessary outgoing requests to the server by introducing the waterfall.

Do other examples come to mind?

[TkDodo]

we're using this pattern for mandatory data that we need on different pages. But yes, it's mostly user data :)

[AjayTheWizard]

I found a Typo in Code Example under the Heading Being self-contained.
Here fixed code,

export const useUserQuery = (id: number) => {
  return useQuery({
    queryKey: ['user', id],
    queryFn: () => fetchUserById(id),
  })
}
export const useCurrentUserQuery = () => {
  const id = useCurrentUserId()

  return useUserQuery(id) // <-- Here's the Fix
}

[TkDodo]

thanks - can you PR this? code is open source: https://github.com/tkdodo/blog

[baeharam]

Thanks for your great article! 👏

[lgenzelis]

Great advice, thanks a lot for sharing this Tk!! 😁😁

[raphaelbadia]

can't wait for v5!

[jtgi]

Nice. Glad it's not just me.
As you mentioned, I don't like side stepping the compiler. I find others may not understand why and I prefer the explicit dependency.

I've been using it with react-router's outlet context and nested routes, works decent, e.g:

function Routes() {
  return (
    <Routes>
      <Route match="/:id" component={ResourceLayout}>
        <Route match="/edit" ... />
      </Route>
    </Routes>
  )
}

function ResourceLayout() {
  const id = useParams();
  const resourceQuery = useResourceQuery(id);
  
  if (resourceQuery.data) {
    return <Outlet context={resourceQuery.data}
  }

  // [...]
}

function useResourceContext() {
  const context = useOutletContext<ResourceContext>();
  invariant(/* ... */);
  
  return context;
}

[Tiberriver256]

Nice! I also use React Context as a DI mechanism for React Query. Instead of injecting the data though I inject a service implementation. Makes it easy to swap everything out with mocks as needed.

https://github.com/Tiberriver256/react-query-dependency-injection/tree/3--react-query-dependency-injection/src

[amin-da]

thanks for great article
can you explain more about the dependency injection ? what does it mean in programming? what is the difference between it and the state manager?

[TkDodo]

dependency injection is about taking a static value that doesn't change in the lifecycle of your App and passing it to your App. With it, you have to chance to swap out implementations, e.g. for testing.

https://en.wikipedia.org/wiki/Dependency_injection

[danbeo95]

Great!
Wait for next sharing

[sebastianlp]

Thanks for this, it's really amazing and I'm glad that is a tip since I've been using this to get application settings and I always wonder if it's a bit out of the "rule", I have a question tho, since I found myself doing this when testing components that are wrapped in this provider and bc the provider is in charge of the query, it returns a loader, an error or the children depending on the query status I've always wait until the loader component is not in the screen anymore but I feel it's a repetitive solution, what do you think would be the best approach to test components that are children of this component to avoid waiting for the loader to disappear? I was thinking to provide a customQueryHook that always returns false to isLoading & isError and returns a mocked data object

[TkDodo]

what do you think would be the best approach to test components that are children of this component

you wrap them in a provider that contains data in a non-loading state.

[OBats]

Hi Dominik. Top-notch content as always!

Just curious, should we check if the data was successfully fetched before passing it as a value? TypeScript still infers it as possibly undefined:

  return (
    <CurrentUserContext.Provider value={currentUserQuery.data}> // data is User | undefined
      {children}
    </CurrentUserContext.Provider>
  )

So, would it be a correct approach to do something like this?

  return (
    <CurrentUserContext.Provider value={currentUserQuery.isSuccess ? currentUserQuery.data : null}>
      {children}
    </CurrentUserContext.Provider>
  )

[TkDodo]

My example does checks upfront. By excluding loading (ok, pending in v5) and error, it will always be defined:

  if (currentUserQuery.isLoading) {
    return <SkeletonLoader />
  }

  if (currentUserQuery.isError) {
    return <ErrorMessage error={currentUserQuery.error} />
  }

  return (
    <CurrentUserContext.Provider value={currentUserQuery.data}>
      {children}
    </CurrentUserContext.Provider>
  )

[OBats]

Oh.. now it is clear... I was using isLoading with v5.
Thanks)

[ssrihari4102]

Thanks for documenting this pattern! It was really helpful when setting up my app since it allowed me to have a top level loading state while ensuring data was defined in each component. I was wondering if there might be a way to use this context approach while also reaping some of the benefits of tracked queries? I'm struggling to think of a way to do so.

As an example, let's say the data I am fetching is an object with 20 keys. Each of my components uses 1-3 keys from the data object. Right now I'm passing the entire object through context after ensuring there is no loading or error state, so when I update the data, every component re-renders rather than just the components that use the changed fields.

I'd imagine I should either not worry about optimizing renders in this case or somehow split up the context, but was curious if there might still be a way to take advantage of some of the tools react query provides out of the box to assist with such optimizations.

[TkDodo]

I think this is just the drawback of context here. once the proposal of using context inside useMemo (with the help of use(Context)) ships, this should automatically work.

[ssrihari4102]

Oh that's interesting. I realized after sending my message but Suspense should help with this issue as well right? Namely, like your blog post mentions, we get a similar architecture like we do with context, but are able to just use react query's API, so I imagine we'll be able to use tracked queries by default