Allow passing custom client to useQuery/useMutation

[nandorojo]

I'd like to propose adding the following API:

const client = createClient(...)

useQuery({ client })

We have multiple graphql endpoints with different caches in our app, each using URQL. They have overlapping names in some cases and thus cannot share the same cache. There have been some discussions about multiple endpoints in the past. However, they do not solve the problem.

Simply passing a different context.url doesn't solve the problem of a different cache.

Meanwhile, I could wrap certain components with a different provider. But this doesn't scale well and isn't a very composable API. Some components want to access both caches.

I'd implement this by making my own context provider at the root of the app, and inside a custom useQuery wrapper, I would pass down this client.

The new cilent-preset methodology from GraphQL Codegen makes this approach much more doable.

[JoviDeCroock]

I guess we could consider that as we do support it in vue/svelte, in (P)React we are currently relying on context exclusively. I don't think there are roadblocks remaining for doing this, i.e. previously we had an exchange to facilitate Suspense which could have blocked this.

Previously however we have declined this, #429, because context boundaries often imply data hierarchy and it could indicate that the hierarchy might be a bit odd. Would love to know the use case here

[nandorojo]

To avoid breaking the rules of hooks, it could
make sense to pass a useClient option. Then, in useQuery:

(useClient || useClientContext)()

[kitten]

To expand on what Jovi is referencing, we declined this because of an architectural decision. Of course, many integrations could accept multiple clients.

However, this is always a sign of one of two things:

• Either, you have some kind of client that handles an admin API, in which case a separate section of your app may have a different client. No complaints here, this is a React Context concern.
• Or, you have multiple schemas and APIs and are trying to mix them in your API. This to me is a big sign of a major problem.

In the second case, which I suspect is what you're having, you're basically thinking of GraphQL like "just an API" rather than a data graph.

Of course, there'll be some cases where it's unreasonable to merge schemas, and of course it's sometimes unreasonable to modify or federate schemas. However, if you have mixed data in your app, and in mixed hierarchies you're querying both, that's a sign to me that this should be abstracted to one client.

In other words, when I hear this, my first reaction is that I'd write an exchange that alters the target API based on the query that is sent. Maybe even splitting the exchange streams in two parts when the caches clash (which usually doesn't happen to be fair)

[nandorojo]

I understand the hesitation with the architecture. I'll try to explain our reasoning without revealing too much about our company plans.

We have a core company product for booking live music events. This uses a single graph for all requests.

We are also building a new product with a separate app. Think of it kind of like Uber & UberEats. They are separate apps, but you can also use some UberEats features inside of Uber itself.

The same thing will be the case here: we want our two products' GraphQL schemas to live separately for a few reasons. One reason is, the second product may be exposed as a public API for other people to use someday.

To reiterate: we have our core product, and a new product. The new product may sometimes want to mix into the core one to let them integrate nicely. However, we don't want to have to include all the entire graph of the new product in the core one. We want them to live separately to maintain the flexibility of splitting the new product into an API for developers in the future.

Now, the reality is, names will overlap. Things like __typename: 'User' are hard to avoid.

As for the implementation with a library like urql, I don't have strong opinions about how it should work. Using a custom client felt like an easy way to do it, but I'm open to other suggestions, such as an exchange to separate the caches.

In our admin app, using a separate React Context was an easy solution. But this case is a bit different.

[nandorojo]

I'll have to give this all some thought after hearing your feedback. Maybe we should be just use React Context to denote separate caches for our new product's features and leave it at that.