Is it possible to use Document Caching to invalidate a specific cache **only on success**?

[k4a-l]

I am using Document Caching

We have the following project page,

• The query __typeName is 'Project'
• After retrieving data with this query and updating it on the screen, update the project with mutation updateProject
• updateProject response is a boolean and does not include the __typeName & we want to reacquire the search results displayed next to the project when updating the project, so we set the additionalTypeNames to ['Project ','Search']

The problem is that even when the updateProject fails, the cache is invalidated and reacquired.
The reacquisition triggers a redraw of the screen content, so input is lost despite the failure.

Maybe it is possible to use Normalized Caching, but is it possible to use Document Caching to invalidate a specific cache only on success?

Of course, it would be possible to solve this problem with application logic that keeps the response result and replaces it on success, but I would be very happy if urql's functionality could make this happen.

[kitten]

updateProject response is a boolean and does not include the __typeName
even when the updateProject fails, the cache is invalidated and reacquired.
reacquisition triggers a redraw of the screen content, so input is lost despite the failure.

I'm just boiling this down to the above three quotes first.

First of all,

even when the updateProject fails, the cache is invalidated and reacquired.

To state simply how the API works, once you “tag” a query and mutation with additionalTypenames, that’s a definitive tag. The safest option is to always invalidate.

In other words, although you have a specific case where invalidation isn't expected, the document cache especially will always err on the side of treating invalidating as the safe option. In other words, the reason the document cache exists is because, when we map GraphQL data to our UI and want it to stay up-to-date, we just want to re-execute slightly fewer operations than renders to keep it up-to-date.

So, this is expected.

updateProject response is a boolean and does not include the __typeName

The simplest answer here is, please don't do this. I know a lot of people are tempted by this, but it's bad schema design for three reasons:

• The boolean now encodes your interpretation of a binary state, that isn't obvious for anyone (even maybe a colleague) consuming the schema. Mutation.updateProject: Boolean! can lead to confusion, Boolean (nullable) to even more confusion
  • A false state can now mean a mutation hasn't executed, or nothing's been done. Or something's been done but it's been unsuccessful
  • If any value but true can ever be resolved, when would this deliver a GraphQL Error?
  • It's ambiguous in what changes have actually been applied, which is undocumentable in this result.
• It makes it ambiguous what happens in exceptional cases, i.e. only true is a self-explainable value. Suddenly, you may instead of delivering a GraphQLError result, deliver a false scalar value. What does that means? What would a null mean?
• There's now no way for a Client to update its state. This obviously doesn't seem like a big deal with a document cache, but, as you found out, it limits your options. Since you don't have a way to know what changed, and not even a reflected Project selection set, you can't invalidate properly.

So, with our without a normalized cache, I'd consider changing this at least to:

type Mutation {
  updateProject(id: ID!, input: ExampleInput): Project
}

This is not a big change for the implementation and delivers an updated Project entity to your UI. Even if it's not used this indicates what a successful and error state is unambiguously, as it only allows for error states (with a GraphQLError, albeit optional), or the entity that's been updated itself.

reacquisition triggers a redraw of the screen content, so input is lost despite the failure.

Last point, I'd be careful here.
Of course, both Graphcache and the document cache (because the latter just stores JSON results exactly/unmodified) give you the same references as far as they haven't changed.

But you may want to make sure that your UI can cope with changes — i.e. if your inputs are important, you may want to make sure that a refetch can't destroy them.

If your users rely on updates while also making inputs, I see this as a symptom of future problems. It's hard to chase “zero updates while editing” and a much longer journey of potentially worse UX/DX, rather than investing time now to make sure that user-editable UI can cope with refreshes.

That's easily said, I know, but that's about it.

To summarise, this is all expected behaviour to me.
In Graphcache, you of course have more abilities and cache configs to smooth over schema shortcomings, but it's still more code that has to be written because to shorten this into a neat and short statement; your schema doesn't cater for your app.

Hope that makes sense ✌️

[k4a-l]

I deeply appreciate your very courteous response!

• Do not expect invalidation in specific cases, as it is always a safe option
• The use of boolean types is not appropriate as a schema design, consider a schema that shows clear error and success states
• Ensure that the UI does not lose input due to reacquisition

I will review the design of the application with these in mind.

[kitten]

Perfect, glad it was helpful! 🙌 Let me know if you have any questions after taking a new look at your application. If you do need to take a shortcut, I'm also happy to give some alternatives and options, of course