Hooks independant of context

[ecyrbe]

Hello @TkDodo @tannerlinsley ,

Here is an idea to get rid of react context issues that come mainly from micro-frontend setups, users wanting to isolate context or bundler issues like #4346

The idea is to have something like tRPC client proxy or Zodios hooks instance that could allow to bind react-query QueryClient instance to your hooks without any react context involved.

Indeed, context allows have separation of queryClient from hooks. Meaning you can have the same code used in different context and don't care which one is used.
But this use case is really rare. Usually when using multiple contexts it's to have isolation, meaning that for these use cases, the code is most likely not shared. Else why would you need isolation ?

So the idea is to remove context completely from the equation. Here an example :

import { QueryClient } from '@tanstack/query-core';
import { QueryHooks } from '@tanstack/react-query-hooks';
// in isolated client 1
export const queryClient1 = new QueryClient();
export const queryHooks1 = new QueryHooks(queryClient1);

// in isolated client2
export const queryClient2 = new QueryClient();
export const queryHooks2 = new QueryHooks(queryClient2);

Then in your isolated components

import { queryHooks1 } from './client1';

function myIsolatedComponent1(props) {
  // developper need to know which instance to use explicitly
  const { data: user } = queryHooks1.useQuery({
    queryKey: [ 'users', props.id ],
    queryFn: () => fetch(...)
  });
 return (<div>{user.name}</div>);
}

import { queryHooks2 } from './client2';

function myIsolatedComponent2(props) {
  // developper need to know which instance to use explicitly
  // for example for an admin information access
  const { data: users } = queryHooks2.useQuery({
    queryKey: [ 'users' ],
    queryFn: () => fetch(...)
  });
 return (<div>{users.map(...)}</div>);
}

Obiously this design has some impact. For example to evoid duplicated implementation, you will want to implement this @tanstack/react-query-hooks above current @tanstack/react-query .
This means allow current hooks to not use context optionnally like this :

import { useQuery, QueryClient } from '@tanstack/react-query';

const client = new QueryClient();

function myComponent() {
  // since we pass the client to useQuery, the hook will not try to access context to get the client
  const { data }  = useQuery({
    queryKey: ...
    queryFn: ...
    queryClient: client
  });
}

Let me know what you think about this.

[TkDodo]

So what you are suggesting is: instead of passing a context to useQuery, we would pass a client to it directly ? The normal hooks could read that from context, but the created hooks could use the client that was passed in. Something like:

const useBaseQuery = (options, client) => {
  const queryClient = client ?? useQueryClient() // context can be called conditionally 🤪
}

and the created hooks could be:

const createQueryHooks = (client) => {
  return {
    useQuery: options => useBaseQuery(options, client),
    useMutation: options => useMutation(client)
    // and so on..
  }
}

Let me also tag @blackarctic as he implemented passing in the custom context. If it worked that way, would the custom context be unnecessary? I wouldn't really want to have both apis sticking around ...

[blackarctic]

Passing the queryClient would also accomplish the original goal of pairing the context of the provider with the hook, since queryClient can be passed a custom context upon creation. Sounds like this would also pave the way for this feature being available in more frameworks than just React so this sounds like a better approach to me.

[TkDodo]

yes, when we added the custom context, we didn't have any other framework adapters. It make a lot of sense now

[ecyrbe]

It would be unecessary for isolation. But not relying on an instance to use the hooks will still easier for a majority of use cases.
But like i said, for isolation, it would be the other way around, instance would be easier.

[TkDodo]

right, I could see us doing that for v5, given that we are framework agnostic now, it might also be better for vue/solid/svelte.

Would this also allow us to get rid of context sharing @ecyrbe ?

@DamianOsipiuk @ardeora what do you think?

[ecyrbe]

yes, with this, i think you can put context sharing into trash.

[DamianOsipiuk]

@TkDodo Soooo.... It's already part of vue-query 😅
https://github.com/TanStack/query/blob/main/packages/vue-query/src/useBaseQuery.ts#L50

[TkDodo]

@DamianOsipiuk I had no idea that vue-query has a different api for this 😅 . It makes even more sense for us to streamline this behaviour in v5 then 🙌 .

[ardeora]

This is great! This could also be helpful in creating queries outside a component tree that could be shareable among multiple solidjs components. Could also use the already familiar createQuery syntax for stuff like prefetching, invalidating, refetching, (etc) common queries, For example,

import { createQueryHooks } from '@tanstack/solid-query-hooks'
import { QueryClient } from '@tanstack/solid-query'

const client = new QueryClient()

const { createQuery } = createQueryHooks(client)


const Parent = () => {
  return (
    <>
        <Child1 />
        <Child2 />
    </>
  )
}

const commonQuery = createQuery({
    queryKey: ['common'],
    queryFn: async () => { ... } 
})

const Child1 = () => {
  return (
    <>
        { commonQuery.data?.map(d => <div>{d.text}</div>) }
    </>
  )
}

const Child2 = () => {
  return (
    <>
        { commonQuery.data?.map(d => <p>{d.text}</p>) }
    </>
  )
}

A caveat with this approach is that the subscription for that query would never be disposed. Don't know how big of a performance hit that would be.