-
Notifications
You must be signed in to change notification settings - Fork 4
Make SimpleApolloStore.apolloStore public and add SimpleApolloStore GC extensions #134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -20,8 +20,8 @@ import kotlin.reflect.KClass | |||
* A wrapper around [ApolloStore] that provides a simplified API for reading and writing data. | |||
*/ | |||
class SimpleApolloStore( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not directly related to this PR but I would probably do the opposite naming choice. Keep ApolloStore
for the thing that is used the most (this) and use something else for ApolloStore
. Maybe even possibly hide it from public API altogether?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm we still need both the wrapper and the “wrapped” to be public because setting it takes the wrapped but getting returns the wrapper
// setting
fun ApolloClient.Builder.store(store: ApolloStore, writeToCacheAsynchronously: Boolean = false): ApolloClient.Builder
// getting
val ApolloClient.store: SimpleApolloStore
Re: naming, we could do ApolloStore
→ IApolloStore
and SimpleApolloStore
→ ApolloStore
but not super fan of I
and it’s different from what we do elsewhere.
Maybe at least SimpleApolloStore
should be called something else (but not sure what!), since it’s not an ApolloStore
implem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting it doesn't really need a store, does it? I suspect most of the users use the .normalizedCache()
function, and not .store()
?
The only use case for using .store()
is if someone wants to use their own ApolloStore
implementation but I'm not sure what that would be useful for....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect most of the users use the .normalizedCache() function, and not .store()?
Most probably yes (that's what we show in the docs).
Also not sure of specific use cases to bring your own implementation (but IIRC Netflix does it 😅) - but I think it's a nice flexibility to be able to do it and would be a bit sad to remove it IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, .apolloStore
now returns ApolloStore
, which is the wrapper. The interface is now called CacheManager
.
No description provided.