Pass queryClient as first argument of initialDataFn

[mijamo]

My use case:

• I want to achieve something like https://react-query.tanstack.com/guides/initial-query-data#initial-data-from-cache
• I use SSR and as such I separate my query objects from my components. They live in separate pure JS modules so that I can import the query objects and prefetch them in my server script.
• The current documentation calls queryClient, which is NOT an argument of the function but should be optained independantly. In most cases using useQueryClient should be enough, but in my case I build the query objects outside my React components, so I cannot use hook.
• As a result I cannot have stable (constant) query objects but I need to have factories that take in the queryClient. It complicates the code and adds some unstability (my initialData function is now recreated everytime my component rerenders for instance)

Maybe there's a better way to handle it but I think passing queryClient to the initialData makes sense as it is a very common workflow, in the same way as the queryKey is passed to the queryFunction

[TkDodo]

but in my case I build the query objects outside my React components, so I cannot use hook.

useQuery calls useQueryClient under the hood, so wherever yo do useQuery, you can also do useQueryClient. If you build the query config outside of react, you'd need to pass the queryClient there:

const buildQueryConfig = (queryClient) => ...

const MyComponent = () => {
  useQuery(buildQueryConfig(useQueryClient()))
}

[GLabat]

Jumping into the discussion after reading the last message.

When query configurations are built outside of hooks, queryClient is often required (dependent queries for ex).
As explained above, it is required to pass it.

Inspired by this awesome article ;), a queryConfig would look like:

{
  queryKey: keyFactory.detail('someId')
  queryFn: functionRelyingOnQueryFunctionCtx
}

Here comes the question:

If functionRelyingOnQueryFunctionCtx requires an object given by another query, it makes the configuration a bit more complicated.
Could it be possible that the "ambient" queryClient be part of the QueryFunctionCtx?
This way, functionRelyingOnQueryFunctionCtx could rely on it to retrieve the external object. The logic remains encapsulated and the query configuration simple.

I'm not sure that this is possible but it would be great to have your feedback on it.
Thanks.

[TkDodo]

it would be possible to add the queryClient to the queryFunctionContext - but I fail to see which problem that would solve. It would only be available to the queryFn - the function that does the actual data fetching - where it wouldn't be of much use...

[GLabat]

Hi and thanks for taking the time to answer.

Let me try to explain a bit more.

In our app, we use schemas (JSONSchema-like) to describe our entities.
We setup a helper function getSchemaQueryConfig(schemaName, queryOptions) to retrieve the configuration (queryKey, queryFn and some options) of a query for a given schema.
We also have a hook useSchema which uses this helper to build a query config which is then passed to useQuery.
This "solves" the problem of retrieving a schema in the "React world".

For the "JS world", a helper async function getSchema(queryClient, schemaName, queryOptions) is defined and also relies on getSchemaQueryConfig to build the query config and pass it to fetchQuery.

With this in place, we do not have to bother anymore about query key, query function, cache options etc. to retrieve a schema, which is great.

We decline this pattern of query configurations to retrieve other entities.
But for the query configurations for which a schema is required, this is a bit more complex.
We also want query configurations to be "just" configuration, in the sense that it must only return a configuration, no call, no async stuff, etc.

For ex

function getStuffEntityQueryConfig(stuffOptions, queryOptions) {
return {
    queryKey: stuffKeyFactories.someFactory(stuffOptions),
    queryFn: async queryFunctionCtx => {
      // We want Stuff schema to be retrieved here so that in case of failure,
      // the Stuff query would fail too.
      // This means that the `queryClient` is required here so that we could
      // rely on the cache to get the schema.
      const stuffSchema = await getSchema(queryClient, SCHEMA_STUFF)
      const { extract, some, props, from, schema } = stuffSchema
      return fetchStuffFn(
        queryFunctionCtx,
        { extract, some, props, from, schema }
      )
    },
    ...queryOptions
  }
}

As you can see, this pattern requires an instance of the queryClient.
One way of having it (this is what we do for now but raised this discussion) is to pass it as argument of getStuffEntityQueryConfig => this complexifies a bit the call.

Another way would be to have the queryClient in the queryFunctionCtx passed to the queryFn, which would leave the configuration getter autonomous.

Hope this clarifies a bit.

Thanks.

[TkDodo]

hmm, we internally get the queryClient via useQueryClient ourselves. useQuery creates an Observer, which also has the client. Basically, the client doesn't really do anything. We pass it down react context for easy retrieval. If you want to access the client from outside of react, you can also just export const queryClient = new QueryClient() where you create it and then import it

[TkDodo]

however, composing query functions from other queries of the same client seems useful. for example, you can currently do this via:

const queryClient = useQueryClient()
useQuery(key, () => queryClient.getQueryData(something) ?? axios.get(...))

if the query function is not inlined, passing the client is necessary, so I agree that having the client injected might be useful in some cases. I'll definitely think about it :)

[GLabat]

SSR stuff…

Sorry to have "polluted" the initial question… which was not from me…
Should we open a dedicated discussion?

---

what I like to do is have sharable objects / factories for the queryKeys - even though I also have them as hooks sometimes (useQueryKeys()) because they internally use some id from the url for example. That is needed imo because we have many places where we need to have access to the key, mainly when performing query invalidation.

We definitely agree here. "Query Keys are key" and we should define the logic once. And provide helpers (hooks, factories…) to get a value without having to "know" how the key is made.
The same logic could be applied to invalidations as well. Define business-oriented helpers: invalidateCompletedTodos for ex to minimise key exposure.

---

Another good way to share options between useQuery and prefetchQuery, if necessary, is to use queryClient.setQueryDefautls, which sets default options on a per key basis:

I think this is a good candidate for our sharing case, which still raises some questions.

Ex:

• for ['todos'] key, the queryFn logic would be: get the schema, process schema, fetch todos
• for ['todos', someTodoId] key, the queryFn logic would be: get the schema, process schema, fetch the given todo

So we would still have the need to factorise common part of the query function.

Will give it a try and get back to you.

---

About the addition of queryClient into QueryFunctionContext. Do you want us to create an issue?

Thanks.

[TkDodo]

About the addition of queryClient into QueryFunctionContext. Do you want us to create an issue?

yes, let's track that in an issue please. I still need to think about it a bit, but right now, I could see this make it to v4 :)

[GLabat]

👌will do it tomorrow.

[GLabat]

Here we are: #3151

[GLabat]

I setup a code sandbox to test the queryDefaults pattern. It seems to work as expected and solve our main issue: having access to the queryClient inside a queryFn, outside of hook.

The sandbox is here: https://codesandbox.io/s/react-query-and-query-defaults-vywtm?file=/src/App.js

Would be great to have your feedback on this design.
Thanks.