đź‘‹ Trying to wrap my head around normalized cache and looking for some help:
I have a query like
Copy code
query Accounts($filter: Filter) {
accounts(filter: $filter) {
id
type
name
}
}
where the parameter is a filter and it’s optional. If no filter is given, you get an unfiltered list.
The main screen in my app requests this data with
filter: null
so it can get all the accounts. A detail screen requests the data with
filter: {type: OPEN}
.
I’m seeing a cache miss when I go to the detail screen. Is there a way for the detail screen to get cached data from the main screen even though the params are different?
David Albers
09/26/2022, 2:43 PM
I have a CacheKey setup to use the id:
CacheKey("Account:${obj["type"]}:${obj["id"]}")
. I assume there’s something there I need to change but I’m not sure what.
b
bod
09/26/2022, 2:52 PM
Hi! If you give it a different filter, the returned value would usually be different, so you can't really use the cached value, right?
d
David Albers
09/26/2022, 3:27 PM
hmm, that’s a good point. I guess there’s no way for Apollo to “know” how to filter the data.
b
bod
09/26/2022, 3:30 PM
exactly 🙂
m
mbonnin
09/26/2022, 3:33 PM
You could do something using the low-level
CacheResolver
API
mbonnin
09/26/2022, 3:34 PM
It's going to involve a fair amount of non-trivial code but if you know that
filter: null
is always the same as
filter: {type: OPEN}
, you could handle that programmatically
mbonnin
09/26/2022, 3:36 PM
The default resolveField is doing something like this:
Copy code
val name = field.nameWithArguments(variables)
if (!parent.containsKey(name)) {
throw CacheMissException(parentId, name)
}
return parent[name]
}
So if you can make it so that
name
above becomes
accounts(filter: null)
whenever
{type: OPEN}
is passed, data will be looked up from the parent record