feat(trpc/next): allow passing complete QueryClient instead of queryClientConfig

Describe the feature you’d like to request

When using createTRPCNext, we can pass in a queryClientConfig in the config-callback, for example:

export const trpc = createTRPCNext<AppRouter>({
    config({ ctx }) {
        return {
            queryClientConfig: { defaultOptions: { queries: { staleTime: 20 * 1000 } } },
        }
    },
    ssr: true,
})

trpc then creates the queryClient for us:

https://github.com/trpc/trpc/blob/18a2757a996187f4637f3bcd7ba3080e3c0198a1/packages/next/src/withTRPC.tsx#L105

https://github.com/trpc/trpc/blob/18a2757a996187f4637f3bcd7ba3080e3c0198a1/packages/next/src/withTRPC.tsx#L174

However, the config alone is not enough to define all defaults. If you want to use queryClient.setQueryDefaults to set default values for some queries only, we often do this:

const [queryClient] = React.useState(() => {
  const client = new QueryClient({ defaultOptions: { queries: { staleTime: 20 * 1000 } } })

  client.setQueryDefaults(['todos'], { staleTime: Infinity })

  return client
})

this will make sure that:

• all queries have a default staleTime of 20 seconds
• queries that match the ['todos'] key have a default staleTime of Infinity

This is currently not possible to achieve in trpc because we don’t have access to the queryClient after creation, but before it is put into the QueryClientProvider.

Describe the solution you’d like to see

I’d like to pass the complete QueryClient to createTRPCNext instead of just the config. If we create the QueryClient on consumer side, the problem would not exist.

Desribe alternate solutions

alternative 1

trpc.useContext() could grant access to type-safe wrappers of setQueryDefaults / setMutationDefaults, like it does for invalidate. However:

• this access must exist on the top level (each nested router level) because we likely want fuzzy matching, so it depends on:
  • https://github.com/trpc/trpc/pull/2713
• we would technically need to read-and-set this in an effect because the operation itself is not pure, but if we render our app in the meantime, the queries would pick up the wrong defaults, and also, it wouldn’t work on the server.

alternative 2

we could amend the api of the QueryClient constructor in react-query so that multiple, imperative calls to setQueryDefaults become unnecessary. I am considering this (open for api proposals, too), but I think it would be an orthogonal change to trpc because calling queryClient.setQueryDefaults is still something you can do at any time in react-query, but not really in trpc at the moment.

Additional information

No response

👨‍👧‍👦 Contributing

• 🙋‍♂️ Yes, I’d be down to file a PR implementing this feature!

[KATT]

let’s say I’m not needing SSR of queries (I’m just thinking it’s not worth the troubles right now), would I just add the providers manually instead of doing withTRPC around my app?

Correct - see https://trpc.io/docs/v10/react

[KATT]

No, not right now. Would require some sort of API change where we wouldn’t use the withTRPC-HOC and instead wire it up in a more manual/advanced mode