Are there any particular recommended patterns/appr...
# apollo-kotlin
j
Are there any particular recommended patterns/approaches when using
watch
with endpoint that supports paging?
b
I’m afraid we don’t have anything specifically around cache+pagination yet, but it’s on the roadmap!
👀 1
👍 1
happy to hear any usecases / suggestions you have on that topic, too!
j
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
b
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 🙂
j
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?
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?)
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
b
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!
p
We have a paginated query that returns us a list of our app
items
, like so…
Copy code
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?
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
b
I think that’s correct @Paul Davies and thanks for adding your use-case to the issue, that’s useful!