Are there any particular recommended patterns/approaches when using `watch` with endpoint that suppo...

# apollo-kotlin

[John O'Reilly]

Are there any particular recommended patterns/approaches when using watch with endpoint that supports paging?

[bod]

I’m afraid we don’t have anything specifically around cache+pagination yet, but it’s on the roadmap!

[bod]

happy to hear any usecases / suggestions you have on that topic, too!

[John O'Reilly]

nothing too important....was just thinking of how https://github.com/joreilly/MortyComposeKMM might be migrated over to use the cache and use of watch

[bod]

oh yeah that would be very cool to have it using the cache! We don’t have a real sample app for that on our side 🙂

[John O'Reilly]

I guess an initial question would be what would get get from the watch in this case....the data associated with particular page you queried....or the list contain all data retrieved so far?

[John O'Reilly]

maybe using watch in this case doesn't make sense....if using Android paging library for example (coupled with use of Compose's collectAsLazyPagingItems) then would just use function that queries for particular page of data (which I guess would come from cache if it was in it?)

[John O'Reilly]

I guess where things can get messy then is if/when something updates the data in the cache....and somehow still having setup where you can have reactive UI that's purely driven from data in the cache

[bod]

yes on Android I would definitely go with the Paging library, meaning observing the cache here probably doesn’t apply indeed. Still, pages of data could come from the cache but I think there are some pitfalls that we’d like to address - although to be honest I’m still new to this and haven’t used the cache that much myself yet!

[Paul Davies]

We have a paginated query that returns us a list of our app items, like so…

query ItemsQuery($itemArgs: ItemArgs!) {
    items(args: $itemArgs) {
        edges {
            id
            node
        }
        pageInfo
    }
}

type ItemsArgs {
  first: Float
  after: String
  last: Float
  before: String
  filterBy: ItemsFilterByArgs
}

where the pageInfo contains the pagination info, and ItemsArgs allows us to request a “bucket” of data (usually a month of time’s worth).

The use case is for us to regularly sync our items from the server to the normalised cache, and our UI will watch the cache.

It seems the only way for us to do this is to iterate over the pages in the query, and manually writeOperation the cache to populate it with all the edges (and key it against the original query with no pagination parameter).

Unless there is something I’m missing?

[Paul Davies]

We found this issue - I think this may be what we are looking for (namely relay-style pagination helper and cache persistence)
https://github.com/apollographql/apollo-kotlin/issues/3593

[bod]

I think that’s correct @Paul Davies and thanks for adding your use-case to the issue, that’s useful!