:wave: I think I saw some notion of dependent quer...

# apollo-kotlin

[wasyl]

👋
I think I saw some notion of dependent queries in Apollo, basically that if some query or mutation should refetch some other query (in the background?). I can’t seem to find anything about it in the documentation though, was it a v2 feature or I’m confusing it with something?

[bod]

Hmm, this doesn't ring a bell but maybe this was before my time 🙂

[wasyl]

Found something but for react https://www.apollographql.com/docs/react/data/refetching/! Might be what I saw, but then I suppose it’s not available in Kotlin?

[bod]

no, not directly. But when `watch`ing the cache, a query can refetch from the network when the cache is invalidated. That looks like more or less the same use case, right?

[wasyl]

I’m not sure if if fits our use case:
• query A fetches items filtered by field X
• mutation B modifies X for an item
So we need to refetch A when B happens, but we’d still like B to stay lean, and since A is pretty heavy we don’t want to just fetch it as part of B.
But, nothing about the cache changes from A’s perspective if X changes for an item that wasn’t on the initial list

[wasyl]

🤔 Not sure if I’m clear, the use case is modifying items and having to refresh a list filtered by the modified condition. If the mutation would add to the filtered list, there’s no straightforward way in Apollo to handle that

[bod]

Yeah, if I understand correctly, this probably needs to be custom logic on your app: watch a query that returns X, to trigger query A. When B happens that will re trigger A.

[wasyl]

Yeah 👍
we’re also considering adding the item to the cache manually. Basically this problem of filtered list and mutations that would add to the list seems like a popular one, so I figured maybe there’s some helpful pattern 🙂

[bod]

we don't have anything like that at the moment - don't hesitate to open a ticket for it though!

[wasyl]

We’ll see what we come up with with the problem that we have right now and if it seems useful, I’ll definitely open a ticket to start some discussion 🙂

[bod]

very cool! 👍

[mbonnin]

Re: refetchQueries, there was something in v2. The idea behind not porting it to v3 was that it wasn't heavily used and that coroutines would make it almost as easy and more flexible to chain queries.

[mbonnin]

Re the use case, I think it's a good use case for the new pagination APIs?

[mbonnin]

(although not doable at the moment...)

[mbonnin]

(or is it?)

[mbonnin]

If QUERY_ROOT.edges(filter: "someFilter") has an added node then the watcher should trigger

[wasyl]

How does it know that a node has been added? Are you referring to the pagination APIs (not familiar with those)

[mbonnin]

pagination APIs are pretty much incubating, we haven't really communicated around them but it's something that we're looking into at the moment.

[mbonnin]

How does it know that a node has been added?

The records would merge the lists and I think it should see an addition

[mbonnin]

And add the cacheKey to the list of modified keys

[wasyl]

I’m not sure it can be solved in a generic fashion though, because with filtered list you can as well have 3 queries/lists, and they could contain disjoint filters. So you can’t just add the items without being aware of what the filters are and whether the new items satisfy them, right?

[mbonnin]

Right...

[mbonnin]

Each filtered list would have a different cache key 🤔

[mbonnin]

We "could" have a "main“ list that contains all items

[mbonnin]

And any modification to that one would trigger all the "filtered" lists

[wasyl]

And you’d need some configuration/callback to check whether an item should be added to the filtered list, based on its query?

[mbonnin]

Yeaa looks like it...

[mbonnin]

Would have to be some kind of predicate

[mbonnin]

But you're right that GraphQL doesn't know anything about filters

[mbonnin]

Firebase doesn't have this problem for an example because the filters cannot be arbitrary code. They have a limited number of supported cases