Using cache references

[yaronya]

I have a simple CRUD API, where I can fetch entities by:

1. Context ID - would yield a response with multiple entities
2. Entity ID - would yield a response with a single entity

After digging on the docs and GH discussions I figured that having those two functionalities access the same cache location isn't supported natively by the library and I need to implement such caching logic using the QueryClient methods.
My initial thought was to have this cache structure:

[contextId]: Map<entityId, entity>
[entityId]: entity

Where both queries would use and populate it according to any CRUD operation (I took some inspiration for apollo-client normalized cache structure)

After some time I came to realize that it'd be quite hard for me to sync between the contextId map and each entityId (for e.g - when I remove an entity by id, I'm not aware of the context id that it might have been fetched by, hence I can't remove it from that map and so it leaves the cache out of sync).

I was wondering what's the best approach for me to keep the cache in sync? Perhaps having some cache references or subscriptions. I'd also be glad to hear any thoughts of such normalized cache and whether or not it's a misuse of this library.

Thanks!

[TkDodo]

The simplest approach is to update the queries that you see on the screen and Invalide the rest with invalidateQueries. Those other queries will then refetch when they are used the next time.

Other solution would be to sync manually with setQueryData but that’s pretty tedious and error prone.

[achan-godaddy]

It would be amazing if there was a cache read/write library that we could opt into that does something like https://formidable.com/open-source/urql/docs/graphcache/cache-updates/

if for instance we could get either the server to automatically send id+typename or augment client side then we could have a caching library that follows the convention and so optimistic updates while waiting on the cache to refresh.

The default to updates would be merge but we could also have a delete action to remove from an item or collection followed by a simpler cache update override option. I guess the problem is representing this as a dependency graph to know where to update things.

Still this would solve a huge class of problems for keeping the cache optimistically in synch as soon as possible rather than wait for a round trip or even an onSuccess.

Is this too crazy to work? Urql and Apollo have a different data structure and the problem is definitely challenging but maybe possible to solve?

[TkDodo]

Urql and Apollo have a different data structure and the problem is definitely challenging but maybe possible to solve?

urql and apollo are both graphql sepcific libraries, so they can make certain assumptions (like the existence of an id and a typename field). They also have access to the graphql schema.

This is the tradeoff. react-query is more agnostic, so it will also work with a querFn that is just return Promise.resolve(5), but it also means that things that are more "magic" in other libraries must be done manually in RQ. Sometimes, that means more work in user-land, but it can also mean a more consistent solution without headaches when trying to find out why something does not refetch as expected :)