apollo - 何时使用 Apollo 缓存重定向？

Question

Apollo 文档 discusses the use of cacheRedirects 告诉 Apollo 如何从其他查询访问缓存中的数据。

它给出了一个例子:

In some cases, a query requests data that already exists in the client store under a different key. A very common example of this is when your UI has a list view and a detail view that both use the same data. The list view might run the following query:

query ListView { books { id title abstract } }

When a specific book is selected, the detail view displays an individual item using this query:

query DetailView { book(id: $id) { id title abstract } }

We know that the data is most likely already in the client cache, but because it’s requested with a different query, Apollo Client doesn’t know that. In order to tell Apollo Client where to look for the data, we can define custom resolvers

我试图理解为什么这个例子是必要的。如果 books查询返回 Book 类型的数组，以及 book请求返回 Book 类型的单个对象，那么基于类型名和 ID 以及 DetailView，规范化缓存肯定已经拥有每本书的数据(来自 ListView 查询)。查询可以直接使用该信息而无需任何进一步干预。相反，我们被告知要编写一些代码来帮助它:

const cache = new InMemoryCache({
  cacheRedirects: {
    Query: {
      book: (_, args, { getCacheKey }) =>
        getCacheKey({ __typename: 'Book', id: args.id })
    },
  },
});

在什么情况下 ApolloClient 无法自己解决这个问题，为什么？

Answer 1

给定一个类似于下面的查询，我们正在获取单个 Book，这似乎很明显和直观。对象由它的 id属性(property)。

query DetailView($id: ID) {
  book(id: $id) {
    id
    title
    abstract
  }
}

然而，在这个例子中，这里的参数名称( id )恰好与缓存使用的属性名称( id )相匹配。在惯例之外，没有什么说参数本身不能被称为 bookId , bookID或 supercalifragilisticexpialidocious .即使查询返回 Book type 并接受一个或多个参数，Apollo 无法推断哪个参数实际上是缓存规范化中使用的 id。类似地，如果存在其他参数，它们可能会或可能不会影响当前缓存的内容是否可以使用——需要进一步的逻辑来确定。

这里的另一个考虑是除了可选地传入 IntrospectionFragmentMatcher 的实例之外。给您的 InMemoryCache ，Apollo 实际上并不知道它查询的端点的模式是什么。规范化中缓存使用的类型确定 后 使用 __typename 获取查询属性(property)。整点 cacheRedirects是为了防止在一项或多项已经在缓存中的情况下触发查询。然而，给定一个特定的查询，Apollo 无法知道它会返回一个特定的类型，直到该查询返回之后。 cacheRedirects提供了一种说“此查询将返回此特定类型”的方法，而无需首先触发查询。