Is there a way to get a Flow to watch the cache wh...

# apollo-kotlin

[Jacob Rhoda]

Is there a way to get a Flow to watch the cache when you are reading directly from the cache? I have a query that returns a list of fragments (paginated), and mutations that operate on the CacheKey of those fragments, and the need to consume updates from those mutations.

[Stylianos Gakis]

Is just this .fetchPolicy(FetchPolicy.CacheOnly).watch() what you may be looking for? Unless I am misunderstanding what you mean here.

[Jacob Rhoda]

I need to read the fragment directly from the cache, because my graph QL API does not give me an individual query for that fragment

[Stylianos Gakis]

Aha sorry then I am not sure. You’re looking inside there by doing apolloClient.apolloStore.readFragment() I assume right?

Might be a bit hacky, but could you use one of your queries which does return that type, so you can create a new query which just reads that fragment, and make it CacheOnly and it should just update when cache changes no? But maybe wait for someone who can help you better here 🤕

[Jacob Rhoda]

Hmm… Would it matter if the query is paginated / has other inputs? I don’t know if it would emit changes to the fragment in that scenario.

[mbonnin]

Good question. Fragments are very similar to queries but indeed there's no API to "watch" a fragment

[mbonnin]

From the top of my head, I'd "extend" the schema locally to read the fragment. If you have a fragment like so:

fragment heroDetails on Hero {
  id
  name
  friends(first: $first, after: $after) {
    id 
    name
  }
}

You can extend your query in a extra.graphqls file next to your schema

extend type Query {
  heroDetailsAccessor: Hero
}

Then you can write a query that reads your fragment:

query GetHeroDetails(first: String!, after: String!) {
  heroDetailsAccessor {
    ...heroDetails
  }
}

[mbonnin]

It's a bit of boilerplate so if you use this pattern a lot, we'll want to provide first-class APIs for fragments but in the short term this should work

[mbonnin]

Also you might be interested in this RFC about fragment modularity that intents to make it easier to work with fragments

[Jacob Rhoda]

How would I specify the cache key?

[mbonnin]

If you have an id, you can use fieldPolicy to specify the id:

extend type Query @fieldPolicy(forField: "heroDetailsAccessor", keyArgs:"id") {
  heroDetailsAccessor(id: ID!): Hero
}

[mbonnin]

And then use id in your query:

query GetHeroDetails(id: ID!, first: String!, after: String!) {
  heroDetailsAccessor(id: $id) {
    ...heroDetails
  }
}

[mbonnin]

See also https://www.apollographql.com/docs/kotlin/caching/declarative-ids for more details

[Jacob Rhoda]

Cool! I managed to set this up. I’m trying to consume the flow…but when I call collect, nothing is ever emitted.

[mbonnin]

Are you on v4? v4 will emit the cache misses with some more info in response.exception

[Jacob Rhoda]

No, I’m still on v3

[Jacob Rhoda]

I dumped the cache and it shouldn’t be missing…

[mbonnin]

You can have that on v3 too IIRC. There's a parameter to watch

[mbonnin]

Maybe 'emitCacheMisses' ?

[mbonnin]

(i'm AFK at the moment but can send more details a bit later)

[Jacob Rhoda]

well that seems to have done something at least 🙂

[Jacob Rhoda]

Okay, the cacheMissException is Object ‘QUERY_ROOT’ has no field named ‘fmisFieldRecordDataAccessor({“fieldRecordId”:“26b4bc5f-b338-42ac-8a6f-e4a9c09c5d95"})’

[Jacob Rhoda]

My extended query looks like

extend type Query @fieldPolicy(forField: "fmisFieldRecordDataAccessor", keyArgs: "id") {
    fmisFieldRecordDataAccessor(fieldRecordId: ID!): FmisFieldRecord
}

[Jacob Rhoda]

My query:

query GetFmisFieldRecordData($fieldRecordId: ID!) {
    fmisFieldRecordDataAccessor(fieldRecordId: $fieldRecordId) {
        ...FmisFieldRecordData
    }
}

[Jacob Rhoda]

Ah, I see my problem. The keyArgs should be set to “fieldRecordId”

[mbonnin]

Yep, good call 👍