Are there any particular recommended patterns/approaches when using

watch

with endpoint that supports paging?

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

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

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 🙂

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?

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!

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?

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