Apollo-client: [Question] Clarify inmemorycache and cache redirecting behavior

[JasonLi914]

I'm looking at the documentation for cache redirecting for cache resolvers here: https://www.apollographql.com/docs/react/features/cache-updates.html#cacheRedirect. This is the code I'm referring to:

cacheResolvers: { Query: { book: (_, args) => toIdValue(cache.config.dataIdFromObject({ __typename: 'Book', id: args.id })), }, },

I'm a bit confused by the documentation and had a few questions, answers to any of them are helpful!

1. Is the cacheResolvers feature still supported? It looks to be missing in the documentation here: https://github.com/apollographql/apollo-client/tree/master/packages/apollo-cache-inmemory

2. What is the first argument (_) signify in the function call. When inspecting it, it looks to be a list of id-values to their responses, so I'm assuming it's the list of id values that have been mapped in cache from previous queries for that particular query. So for the book query above, _ would be the list of all the previous query request's id-values, is that correct?

3. I'm a bit confused about when this resolver is called. Is it called on every query to book in the example above, or does it only fire when the default behavior of hitting the cache for the book query misses (it doesn't find it from object id defined in dataIdFromObject or the query path)?

4. Given a book has three different fields 'name', 'date', 'authors', and I was to query for 'name' and 'authors' at some point and then later on queried for 'name', 'date', and 'authors' on the same unique book, will it retrieve 'name' and 'authors' from cache and 'date' from the server? Then afterwards, is the 'date' field added to the same cache object?

5. What happens if the id defined by dataIdFromObject isn't unique? What does the cache look like in this case? In cases like this should the user take more granular control via direct cache accessing?

/label question

[acomito]

It does feel like you need a Phd in apollo-client to do simple CRUD sometimes.

[JasonLi914]

UPDATE: For question number 4, I've referenced this documentation: https://www.apollographql.com/docs/react/basics/queries.html#graphql-config-options-fetchPolicy, which tells me that cache-first is the default strategy. I'm currently trying to use cache-and-network but am running in to unexpected behavior. For me, it never hits my cached query results. For example, I have a basic query that does a search for a user input string and matches all companies that start with that string. So if the user types 'A', they will get the top 10 companies from my GraphQL endpoint that start with the letter 'A'. When I have my FetchPolicy set as cache-first, then the second time I type 'A', it hits cache and my results show up instantly. When I set my FetchPolicy to be cache-and-network, I never see it hit my cache. I know that it will make the network request, but I expect it to first return my cached results while the request is still happening, which I don't see it doing when I look at my results in my result callback (I'm using vue-apollo as a wrapper around apollo-client, which has a hook called result when my queries result changes: https://github.com/Akryum/vue-apollo#advanced-options). From what I'm seeing locally, it returns immediately 0 results from cache and simultaneously makes the network request, and returns back the top 10 results then. However, I know that these results are in cache, because if I change my policy to cache-first, it hits them. My understanding of apollo client's caching strategy is that it first looks for rootQuery path (which if this is true, I would expect my query described above to hit cache this way), and then unique object id's in cache. Could anyone explain in more detail what the cache looks like for queries like this and let me know if I'm misunderstanding something? Thanks!

[leopoldw]

There's also an undocumented third argument, which is an object with a single key: a function called getCacheKey. From my testing it seems to do the same thing as cache.config.dataIdFromObject, but without you having to require the cache object from within the function.

Would be nice to see some docs clarifying what these functions do, as my caches are all missing when they should be hitting - not sure how exactly this cacheKey object matches correctly.

[dralletje]

Actually that getCacheKey, similar to cache.config.dataIdFromObject and toIdValue was what made it not hit the cache in my app. Applying cache.config.dataIdFromObject as well as getCacheKey didn't work.

Try

cacheResolvers: {
  Query: {
    book: (_, args) => toIdValue({ __typename: 'Book', id: args.id }),
  },
},

or with the never version (where it is also renamed to cacheRedirects, they sure do change the API a lot still :) )

cacheRedirects: {
  Query: {
    book: (_, { id }, { getCacheKey }) => getCacheKey({ __typename: 'Book', id: id }),
  },
},

[hwillson]

To help provide a more clear separation between feature requests / discussions and bugs, and to help clean up the feature request / discussion backlog, Apollo Client feature requests / discussions are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

This feature request / discussion will be closed here, but anyone interested in migrating this issue to the new repository (to make sure it stays active), can click here to start the migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!