Manual cache invalidation?

[kasrak]

Hi!

We're using graphcache. In a part of our app, we have a flow like this (simplified for this discussion):

1. There is a list of Items that are fetched with a GetItems query.
2. The user clicks an "Add item" button, which kicks off a StartJob mutation, which queues a background job on the server and returns the job ID. The background job will create a new item (it takes a while, which is why we do it as a background job).
3. The client polls for the status of the job ID. Once the status changes to "done", it manually refreshes the getItems query by calling refresh({requestPolicy: 'network-only'}).

This works, but ends up needing a lot of plumbing to manually refresh where the query is used (sometimes items are created by different parts of the UI).

I saw the docs on cache invalidation here, but I don't think that works in this case because the cache can't be invalidation immediately after the mutation runs. We need to wait until the job finishes running.

Is there a way to manually invalidate the GetItems query when the job completes?

[kitten]

Hiya 👋

Typically for invalidation we’d recommend a cache.invalidate call in a custom updater: https://formidable.com/open-source/urql/docs/graphcache/custom-updates/#cacheinvalidate

Updaters can be used to update a list without a network round trip as this page shows, but you can also use cache.inspectFields to get more information on some listing fields and invalidate them, which will cause a refetch automatically of queries that contain invalidated entities and fields.

So for instance if you invalidate Query.jobs(...) from a Mutation.addJob(...) update, then Graphcache recognises that your query will had some of the data it depends on changed, and will issue a refetch automatically. Since it’s then missing data due to the invalidation it will jump to making a network request.

[nil1511]

Hi Phil, Thank you for the awesome client. we are facing a similar issue, need to invalidate cache after an external API or some other async task. I think cacheExchange expects updates to be synchronous. For now, we are requesting the predetermined Graphql request again. It would be great if we can have access to cache outside update Mutation then we can search for the type of queries to invalidate based on the task and invalidate them.

[JoviDeCroock]

You should already be able to do this, an updater runs once at the beginning of a mutation when an optimistic update is given and once after so based on the result of said mutation you are able to do this.

We've conciously chosen not to expose the cache outside of updaters, ... Since this can cause undeterministic behavior.

[nil1511]

Hi @JoviDeCroock, I have created a CodeSandBox for the useCase. which basically added a promise in Mutation updates.

On adding a todo. the mutation is created. then frontend will update todo list after an external request based on the created resource.

Client: https://codesandbox.io/s/admiring-sun-i4j88?file=/src/App.js:670-724
Server: https://codesandbox.io/s/priceless-swartz-yx26x?file=/schema.js

[JoviDeCroock]

Just wondering about this but wouldn't a subscription be the ideal solution to what you're describing?

[nil1511]

Yes, 😅 it would be more appropriate to use the subscription for this use case.