The 3.0 migration doc mentions: “Watchers now defa...

# apollo-kotlin

[Stylianos Gakis]

The 3.0 migration doc mentions:
“Watchers now default to a CacheOnly refetchPolicy instead CACHE_FIRST. To keep behavior unchanged, set a refetchPolicy on your watchers:”
But the snippet directly under it shows subscribe instead of watch(). Is this wrong in the sense that it should be .watch() instead, or should the title of the section be subscriptions? I am kinda confused at that part of the document.

[mbonnin]

I have no idea what happened in my brain when I typed this... Sorry about this. Watchers are for queries, not subscriptions. It should be .query(query).watch() ...
Fix there: https://github.com/apollographql/apollo-kotlin/pull/4118/files

[Stylianos Gakis]

Hey it’s a small mistake, don’t worry about it 🤗

I do have a question regarding this though then. Looking at the code, watch internally does a toFlow() and then emits the response directly. And only after that it does the copy() with the cache_only policy. Which part am I missing that makes the watch do as the docs suggest aka only fetch from the cache?

Also as a side curiosity question, if we had not configured any cache (http or normalized) would a watch just do nothing?

[mbonnin]

Looking at the code, watch internally does a toFlow() and then emits the response directly.

That's for the initial response only. If you follow the code, you'll see another lower level watch that watches for changed keys in the store

if we had not configured any cache (http or normalized) would a watch just do nothing?

It would return the NetworkOnly response once and that's it.

[mbonnin]

And only after that it does the copy() with the cache_only policy.

Ah, sorry I missed that part. There are 2 things: fetchPolicy and refetchPolicy

[mbonnin]

The migration guide talks about how refetchPolicy is CacheOnly by default

[mbonnin]

I'm not super happy about this API TBH. The fetch vs refetch is a lot of cognitive load. Plus error handling is tough. I'm hoping we can simplify it at some point.

[Stylianos Gakis]

Aha does that mean that before, the refetch was CACHE_FIRST aka if there was a cache miss it would try and hit the network?

[mbonnin]

Yes, exactly

[mbonnin]

Something I missed during the v3 development

[Stylianos Gakis]

Wow yeah very interesting I had no idea!
Yeah I missed the part where it said “refetchPolicy” so I didn’t piece the two things together. Thanks a lot for the clarification! I think I have the correct understanding to move forward with this 🙌

[mbonnin]

There's another lower-level watch() in this file that is not advertized as much because it's a lot newer but has less "logic" inside and exposes what is (I believe) a simpler API

[mbonnin]

The hard part is that you still need an initial set of keys to watch (hence the initial fetch vs refetch in the initial API)

[mbonnin]

(or you can watch everything but that's a lot of events... But maybe it's okay...)

[Stylianos Gakis]

Yeah I noticed that one too, but I am not sure I understood it exactly. What are you referring to when you say “initial set of keys”? And how is the data: D? used in that function? Just looking at the function signature I assume you pass what the first emission of watch will return, and from then on it will return all cache changes, but I am not sure.

And as a side note, In all the times I had to use a watch myself, I did in fact want the behavior of fetch once, and listen after, but I imagine there are other use-cases that don’t have the same requirements. But we’re not relying super much on caching in general, so there’s that.

[mbonnin]

data is used to get the initial set of keys to watch for

[mbonnin]

If you pass null, you will watch for all changed keys

[mbonnin]

Meaning everytime something changes in the cache you'll try to run the query against it and try if it succeeds

[mbonnin]

So that's potentially a lot of querying