feat(react-query): Add client parameter to queryKey and remove options parameter

[jeiea]

Description

I'm referring to these lines.

Add client parameter to queryKey

Currently, the implementation has a potential issue because useQuery calls from different clients are assigned the same key, even though they're querying different endpoints.

For example:

import { default as createFetchClient } from 'openapi-fetch'
import createClient from 'openapi-react-query'

const client1 = createClient(createFetchClient({ baseUrl: 'https://api1.example.com' }))
const client2 = createClient(createFetchClient({ baseUrl: 'https://api2.example.com' }))

function useSomething() {
  return [client1.useQuery('get', '/a'), client2.useQuery('get', '/a')]
}

Here, both queries receive the same key, even though they are querying different sources.

... and remove options parameter

Currently queryOptions spreads the options parameter in the last argument. It might be cleaner to make this the library user's responsibility, as shown in the following examples, which yield the same result but simplify the implementation:

const queryOptions1 = client.queryOptions('get', '/', {}, { enabled: false } )
const queryOptions2 = { ...client.queryOptions('get', '/', {}), enabled: false }

Proposal

The title summarizes the changes.

Checklist

• I’m willing to open a PR for this (see CONTRIBUTING.md)

[Justin-Burg]

Hello everyone,

I also have the problem that useQuery on both the these clients

const client1 = createClient(createFetchClient({ baseUrl: 'https://api1.example.com' }))
const client2 = createClient(createFetchClient({ baseUrl: 'https://api2.example.com' }))

get the same queryKey, just like it's described in this issue.

I think having multiple openapi-react-query clients is a common use case and currently the only option to not have conflicting queryKeys is to make multiple TanStack query clients.
I also noticed that #2004 seems to be an elegant solution to this problem (originally proposed here #1981 (comment)). But it is now closed without comments.

May I ask why it got closed and if there is a different solution planned?

[jeiea]

The main reason is that I lost confidence in the PR changes. Since I haven't actively used TanStack Query, this issue is primarily for adoption investigation.

Another factor is that my motivation has faded due to the delayed adoption.

My final thought before closing is whether wrapping queryOptions or useQuery with a custom function (for providing different queryClient) would be sufficient for handling different baseUrl values. What do you think?