A modern programming language that makes developers happier.

kotlinlang

Interested to hear how you’d suggest improving the case where I’m relying on `watch()` for some query and how I’d handle error cases within it, more in thread :thread:

So at a screen, I was simply doing `.watch()` on a Query in order to update the UI.

This came with the problem where if there is no internet, and nothing is cached, and I did not pass `fetchThrows = true`, the watch would simply not return anything and since no value would even come it’d be stuck loading and no information on the no internet access error would surface on the UI.

Then I thought of adding `fetchThrows = true` to error on the first fetch if it fails (and not `refetchThrows = true` since at that point I can rely on the cache) so that I show the error screen to help them understand that something went wrong instead of showing an infinite loading screen. Now this comes with the problem that since the watch threw, the flow is cancelled and I’d then need something to re-start this watch on a retry button click or something like that.

But then I need some functionality to do this retrying the watch from start again, which is what I’ve done now and it works. But I’m thinking, am I missing something better I could be doing here with the .watch APIs? Something I’m misusing by some chance?

have you tried playing with the "other" `watch`? The one that takes a `D?` and a `retryWhen` lambda

this could allow you to decorrelate querying and watching

(a bit more meta: we're thinking of not throwing in Flows in a future version of the lib, and instead expose an exception in `ApolloResponse` which would simplify this usecase - more info in <https://github.com/apollographql/apollo-kotlin/issues/4003|this issue>)

Sorry for the late reply, got caught up with other stuff, and no I haven’t quite played with the other `watch` signature since I don’t think I quite get it tbh.
I guess how it’d work is that instead I’d do a normal query, get that result and do what I want with the error case, and in case of a successful response I then take that data and feed it into the `.watch` `data` parameter?
I read that issue and yeah sounds interesting to see what approach you’ll go with after all. I’ll keep an eye on it to make sure I am up to date with this decision :sweat_smile: