4.0.0 Pagination scenario: CacheAndNetwork emits the incoming data as-is, rather than the merged result from the cache

[ChlorUpload]

Question

When collecting the flow returned by toFlow constructed with the CacheAndNetwork 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 of apollo-react.

[BoD]

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 pages

You 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?

[ChlorUpload]

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?

[BoD]

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.

[github-actions]

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.