Hey all, I have a question about caching lists. If...

# apollo-kotlin

[Spencer]

Hey all, I have a question about caching lists. If there is a filterable list, that returns a list of nodes, and we were to call a mutation that would add or remove a node from the list (or even pagination), how do we update the cache of the list? Or am I just thinking about this wrong?

Example:
• Let's say there is a searchable list of users, and with out search text the query returns the whole list.
• But then we start to type in the search field and make a new query.
• Then we call a mutation that deleted Bob Smith (or even added a new Bob Smith)
I think the cache would look something like this:

Account:12345.users()
Account:12345.users({search: "Bob"})
Account:12345.users({search: "Bob Smith"})

The problem is that we want to update the cache for all the lists after the mutation succeeded. I have thought about updating the cache manually with writeOperation but we would run into not knowing every single search query text, or having to keep a list of every time a query was made with the search text. The same would apply trying to use refetch queries in the mutation collect, or even just deleting the cache key from the store with apollo.apolloStore.remove(CacheKey(key)) .

[mbonnin]

This is a hard problem with GraphQL because the filters are arbitrary arguments, there's nothing special about them so unless you reproduce the filter logic client side (not easy to do), there's no easy solution to this probelm

[mbonnin]

The closest I can think of is https://github.com/apollographql/apollo-kotlin/blob/05f2a3295517fb7a64c2259c38b453[…]m/apollographql/apollo3/cache/normalized/api/NormalizedCache.kt

[mbonnin]

If you hold a reference to your low level normalized cache, we added this hook specifically for this kind of things. You could delete all the keys that "match" users()

[mbonnin]

Of course that removes from the cache so you need to fetch again. But at least it won't show stale data

[Spencer]

Thanks! That's what I concluded too is that there really is no easy way to solve it.