Entity expiry

[hbriese]

Problem

cache.invalidate removes an entitiy completely, resulting in the query returning null for nullable fields with schema awareness otherwise suspending (if enabled).
This causes the UI to awkwardly suspend when it should show the old data until the query refetches

Desired behaviour

A expire function that refetches any query that references the expired entities with the cache-and-network request policy.
This would refresh the data without completely discarding the old data.

Potential exchange

As a novice to the internal details of URQL, it seems a exchange would be able to accomplish this and would look somewhat like the refocus exchange.

1. Maintain a list of active queries (like refocus) that are cache-first or cache-only
2. When expire is called, find expired queries - those that references expired entities
3. Re-execute queries with cache-and-network

Please let me know if I'm thinking about this problem wrong, or have any suggestions regarding the implementation or otherwise achieving the desired behaviour

[JoviDeCroock]

Personally I am less of a fan of the expiry way of thinking and a fan of client controlled nullability to achieve this, this would behave similarly to Schema awareness only you tell the cache what can be nullable.

The thing with expiry is that it's harder to customise as there's also a lot of data that you don't want to show when it's expired/stale.

[hbriese]

Will a currently rendered query return the old invalidated value if the field is @required?

[JoviDeCroock]

No, but it can return null when it's invalidated and refetching in the background rather than it suspending for instance. You can always memoize the result if you need the stale data or as you say a custom mechanism in terms of your own cache

[JoviDeCroock]

I reckon that stale markers could be implemented but it would probably be some overhead, we have all the data of active-operations/...

[hbriese]

The local caching example you suggested was simple to implement (3 LOC) with almost no overhead, and works well for active operations, but of course doesn't work when the invalidated data is queried by an inactive operation (that is expensive) which is problematic for my usecase.

Both Relay and Apollo both mark the data as stale when you 'invalidate' it, rather than deleting it outright but I respect that URQL takes a first-principles approach and is a great library for it. Would stale markers add the same overhead if built directly into graphcache?

[JoviDeCroock]

I'm not fully sure, what the overhead would be of having it added in graphcache but TLDR

• we would need to track the invalidated fields/entities
• we would need to check whether the record/link is stale
• we would need to indicate that this is a stale-but-return-with-refetch
• last but not least we would need to add it to the shouldReexecute

Some questions to ask oneself would be how this behaves for out-of-band responses (i.e. queries that are already in-flight) as well as optimistic reads.