Closed ChlorUpload closed 5 months ago
Hi! This is the expected behavior, while I can see that it is not very practical.
When using the pagination support, it makes more sense to use
watch
to observe the merged list NetworkOnly
to fetch new pagesYou can see an example of doing this a sample app here.
Is there a case that I'm not seeing where CacheAndNetwork
would be preferable?
I checked your sample app. Thank you!
Now I have a simple question. If I want to refresh the list and load the data from the beginning (like refetch
in apollo-react
), should I clear the cache manually?
One simple way to do this is to fetch the 1st page again from the network (FetchPolicy.NetworkOnly
), which will be interpreted by the ConnectionRecordMerger
as a reset signal.
You could also clear the cache manually via ApolloStore
APIs, but the above is simpler.
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.
Question
When collecting the flow returned by
toFlow
constructed with theCacheAndNetwork
fetch policy, the second emitted data consists of the incoming data as-is, rather than the merged result from the cache.I'm currently in the process of implementing relay-style-pagination in version 4.0.0-beta.5, utilizing ConnectionRecordMerger. I've confirmed that the existing and incoming data merge correctly in the cache. However,
toFlow
emits the merged data from the cache, while the incoming data is emitted as-is. Consequently, the size of the array in the collected data appears as follows: 5, 10, 5, 15, 5, 20, 5, 25, 5, 30, 5, 35, ...Is it intentional for
CacheAndNetwork
fetch policy to emit incoming data? This behavior appears to differ from that ofapollo-react
.