Is there a way to invalidate specific cache entries using the document cache?

[casperOne]

My setup is currently the following:

• A Provider at the top level of the application with a configured client
• Using the default exchanges, so document caching (not normalized cache)
• Multiple sections of the application, each making a call to useQuery
  • useQuery is used here to re-execute query with a different request policy (basically force refresh)

However, there are sometimes issues when querying data from the server; when this happens, we have an error boundary set up which shows a window explaining that something went wrong.

What I'd like to do is to be able to invalidate a specific document in the document cache for the query that is being executed in the appropriate section.

I'd prefer not to invalidate the entire client if possible (but I believe I can if necessary).

I believe I can do this with the normalized cache, but that's a much larger lift which I'm trying to avoid.

Thanks in advance.

[JoviDeCroock]

Hey,

Both of our caches are reliant on the semantics of GraphQL which means that a mutation result (or a subscription trigger - normalized cache) are the best ways to invalidate data. If your ErrorBoundary is some form of mutation you could attach this to the options.context value.

For instance if useQuery.todos fails that has __typename=Todo we could do something like reportError(x, { context: { additionalTypenames: ['Todo'] } } which will invalidate all queries that have a Todo in the results.

The behavior you're describing makes me think you're looking for some revalidate pattern, your queries were a success but as the result of an ErrorBoundary that goes away you want to refetch them, this can be done through an effect as well.

[JoviDeCroock]

Well if this errorBoundary is visible in terms of GraphQL interactions it's possible in the form of additionalTypenames that being said generally we advise to reset the client when this happens outside of GraphQL operations to ensure consistency.

[casperOne]

Thanks for the response.

Yes, the error boundary is visible in terms of GraphQL interactions; how would I go about it with additionalTypenames? Is there an imperative way to do this from the error boundary, or will we have to maintain state that an error occurred and then reset that if there is a successful query?

I may look into a separate client per section of the app; they generally access separate types, but not always.

[casperOne]

Looking further into this, it would be completely feasible for us to maintain a client for each section. However, we'd like to use useQuery in order to do this.

Would it be possible to update useQuery (potentially through OperationContext) so that if a client is passed in, that is the client that is used?

This is where the change would be made:

https://github.com/FormidableLabs/urql/blob/aa3f8ca92aa136d81a47452ab2248857a7e0ff8c/packages/react-urql/src/hooks/useQuery.ts#L52

If the client is undefined (which would be the default, given existing code), then it would get the client from the context.

Is this feasible (and not breaking any architectural requirements/norms/tenets)?

[kitten]

Hiya 👋

We've had some requests like these before, however it's unlikely that we'll add this as it goes towards a direction where it's likely that the approach will cause more harm than good.

The reason is that all of these interconnected behaviours, especially expressed in hooks, cause you to build up complex couplings between what becomes UI state.

Each query, mutation, and subscription express simple update relationships between each other, which is what ultimately makes GraphQL such a nice structure and pattern to use in apps. When you couple these updates together in certain unpredictable ways outside of the "client area" in your UI code then you'll introduce a lot of edge cases that become harder to control in our opinion.

I'd say, typically this sounds like I'd recommend you to create your own document cache and add some manual invalidation logic to it. But I'm wondering whether holding off on the normalised cache (Graphcache) may actually be holding you back here.

I like the idea of the error boundaries and I'm wondering whether this recent feature addition is actually exactly what you're looking for, potentially: #1356

tl;dr: this causes normalised fields (records/scalars and links/relations) to be written as "uncached" or deleted in other words when the cache sees that the field has an associated error.
This means that in the hook you'll see the error, other parts of the app that use the same entities with uncached fields will refetch, and the entire query will be refetched when it's run again. Our docs have more details on how Normalised Caching works in detail if the concept itself just sounds a little overkill to you right now 💙 In short; often it can really be extremely flexible

Edit: basically, to have some meta commentary here. I know you said you tried to avoid normalised caching, but it does look to me like if this feature does exactly what you need and you're considering alternatives that require much more thought then this could maybe actually save you time in the long run

[casperOne]

@kitten Thanks for the reply.

I'd say, typically this sounds like I'd recommend you to create your own document cache and add some manual invalidation logic to it. But I'm wondering whether holding off on the normalised cache (Graphcache) may actually be holding you back here.

Currently, all of the items being returned from the graph QL endpoint are aggregated values; there is no single key value on these records that can be easily mapped to the normalized cache (there are multi value natural keys though).

Yes, I can map them for each type, but that's a lift I'm not willing to make yet. It's extremely arduous to go down that path.

I like the idea of the error boundaries and I'm wondering whether this recent feature addition is actually exactly what you're looking for, potentially: #1356

It looks like it might be able to? But since it works with just the normalized cache, I'm still bound by the issues mentioned earlier.

It's not that I don't want to use the normalized cache, but considering the effort for the lift, when compared against other priorities, it doesn't make sense to utilize at this time (especially since the return seems to be minimal in terms of performance).

Edit: basically, to have some meta commentary here. I know you said you tried to avoid normalised caching, but it does look to me like if this feature does exactly what you need and you're considering alternatives that require much more thought then this could maybe actually save you time in the long run

I've been able to address the issue for now. I have a class (the manager) that produces a version number for the clients for each of the "sections" of my app; this class is inserted into a provider at the top level.

Each section requests the version from the client (using their specific key as a lookup value) which the manager returns. The client is then inserted into a Provider which sits at the top of each section.

When there is an error, we invalidate the value, allowing a new client to be generated and it refetches the content.

The number of times there will be overlap between types that are used in different sections of the app will be small, so having one client cached per section works for us.

Thanks for your help.