Hello! Any reason why `NormalizedCache#merge(com.a...
# apollo-kotlin
e
Hello! Any reason why
NormalizedCache#merge(com.apollographql.apollo.cache.normalized.Record, com.apollographql.apollo.cache.CacheHeaders)
(https://github.com/apollographql/apollo-android/blob/bd707bbcb14741a3d2176ae93007bc42d080d878/apollo-normalized-cache-api/src/commonMain/kotlin/com/apollographql/apollo/cache/normalized/NormalizedCache.kt#L58) is not returning
Set<String>
instead of
Set<String?>
. Both
NormalizedCache#merge(com.apollographql.apollo.cache.normalized.Record, com.apollographql.apollo.cache.CacheHeaders)
and
NormalizedCache#merge(com.apollographql.apollo.cache.normalized.Record, com.apollographql.apollo.cache.CacheHeaders)
already return non-nullable String sets, I find the difference a bit annoying, and it forces me to make a cast to
Set<String>
in our codebase xD Also, technically, nothing is impeding the return type to be a set of non-nullable strings. I am happy open a PR that changes the return type, if you think that it makes sense.
m
I'd say it's a leftover from a Java -> Kotlin automatic conversion
This sounds like it should be non-nullable
A PR is very welcome 😃
e
awesome, thanks for the quick reply! PR incoming!
m
Thanks!
Quick question though: Are you sure you need this instead of the
ApolloStore
APIs ?
NormalizedCache is lower level, IIRC
ApolloStore
does a bunch of additional stuff like locking and notifiying store listeners
(which is maybe why no one noticed until now...)
e
I recently joined my first project that uses GQL. There is this custom framework on top of Apollo that does a lot of clever stuff, but I couldn’t tell you how necessary it is compared to just using ApolloStore, as I am quite new to this tech stack. I will try to forward your question to the people that built this solution though. Sounds like there is a possibility to get rid of some custom stuff that we have to maintain and just use some out of the box components, which is always nice. Thanks for raising it!
šŸ‘ 1