apollo-ios icon indicating copy to clipboard operation
apollo-ios copied to clipboard

Support cache hits irrespective of Query Root Operation name

Open qingqingliu opened this issue 5 years ago • 5 comments

Feature request

Add similar support of CacheKeyResolver as from Android Apollo Client library.

Motivation

Current iOS library provides cacheKeyForObject on ApolloClient that allows you to provide custom cache key for response, but there is no way for client app to provide custom cache key for request. This feature is needed in case client wants to use a different cache key for request

Proposed solution

Follow Android pattern to introduce CacheKeyResolver on ApolloClient and support custom cache key for both response and request key.

qingqingliu avatar Sep 30 '20 19:09 qingqingliu

We're going to be looking in late 2020-early 2021 at getting our mobile caching more aligned, both across iOS and android and with our web cache, and this is one of the things I'll definitely be considering.

I'm definitely open to discussion if you're interested in implementing this yourself.

designatednerd avatar Sep 30 '20 20:09 designatednerd

Thanks @designatednerd for the follow up. I see this is being part of bigger alignment between iOS and Android, I would probably wait for an overall proposal first. Happy to contribute though once the proposal is in place

As android side does seems have more feature supports like refetch, optimistic updates and custom cache key etc, wondering whether the direction for iOS would be following Android design pattern

qingqingliu avatar Sep 30 '20 21:09 qingqingliu

We're going to try to line up on what's best for both - the biggest issue right now is that iOS had a long period where no development took place (while Android was chugging along well with open-source contributions) and I'm still digging my way out of that hole.

designatednerd avatar Sep 30 '20 22:09 designatednerd

Hi 👋🏻 - this issue should be resolved in 1.0. 1.0 is currently in alpha releases with a full 1.0 release in H2 2022. Please take a look at the latest alpha and let us know if this is still an issue for you.

calvincestari avatar May 23 '22 21:05 calvincestari

Reopening this issue as it was incorrectly closed during 1.0 release.

Note that the cache currently requires a response to have been cached at least once before any subsequent requests can prevent a network fetch and use cache data. New requests cannot take advantage of those cached objects because the query root will be different and the only way around this at the moment would be to manually write the missing query root record linking to the already existing cached objects.

calvincestari avatar May 30 '23 20:05 calvincestari