何时使用Apollo的cacheRedirects? [英] When to use Apollo's cacheRedirects?

问题描述

Apollo文档讨论了 cacheRedirects 告诉Apollo如何通过其他查询访问缓存中已存在的数据.

The Apollo documentation discusses the use of cacheRedirects to tell Apollo how to access data that's already in the cache from other query.

它给出了一个例子:

在某些情况下，查询会请求客户端中已经存在的数据用不同的密钥存储.一个很常见的例子是您的用户界面具有使用相同数据的列表视图和详细信息视图.列表视图可能会运行以下查询:

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 {图书{ID标题摘要}}

query ListView { books { id title abstract } }

选择特定书籍后，详细信息视图会显示一个使用此查询的单个项目:

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

查询DetailView {图书(id:$ id){ID标题摘要}}

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

我们知道数据很可能已经在客户端缓存中，但是因为是通过其他查询请求的，所以Apollo Client不会我知道.为了告诉Apollo Client在哪里寻找数据，我们可以定义自定义解析器

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获得了每本书的数据(来自ListView查询)，并且 DetailView 查询可以直接使用该信息，而无需任何进一步干预.相反，我们被告知编写一些代码来帮助它:

I'm trying to understand why this is necessary for this example. If the books query returns an array of type Book, and the book request returns a single object of type Book, then surely the normalised cache will already have data for each of the books (from the ListView query) based on the typename and id, and the DetailView query can use that information directly without any further intervention. Instead, we're told for write some code to help it:

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

究竟是什么情况，ApolloClient无法自行解决?为什么?

Underwhat exactly which circumstance is the ApolloClient not able to figure this out for itself, and why?

推荐答案

似乎很直观，鉴于下面的查询，我们正在通过 Book 对象获取单个 Book 对象> id 属性.

It seems obvious and intuitive that given a query like the one below that we're fetching a single Book object by it's id property.

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

但是，在此示例中，此处的参数名称( id )恰好与缓存使用的属性名称( id )匹配.除约定外，没有任何说法表明该参数本身不能称为 bookId ， bookID 或 supercalifragilisticexpialidocious .即使查询返回 Book 类型并接受一个或多个参数，Apollo也无法推断哪个参数实际上是缓存规范化中使用的ID.同样，如果存在其他参数，则在是否可以使用当前缓存的内容方面，它们可能无关紧要-尚需进一步的逻辑才能确定.

However, in this example the name of the argument here (id) just happens to match the name of the property used by the cache (id). Outside convention, there's nothing that says the argument itself couldn't be called bookId, bookID or supercalifragilisticexpialidocious. Even if a query returns a Book type and takes one or more arguments, Apollo has no way to infer which argument is in fact the id that was used in cache normalization. Similarly, if other arguments exist, they may or may not matter in respect to whether what's currently cached can be used or not -- further logic is needed to determine that.

这里的另一个考虑是，除了可选地将 IntrospectionFragmentMatcher 的实例传递给您的 InMemoryCache 外，Apollo实际上并不知道端点的模式是什么查询.在 之后使用 __ typename 属性获取查询后，确定规范化中缓存使用的类型. cacheRedirects 的全部要点是，如果一个或多个项目已经在缓存中，则可以防止触发查询.但是，给定特定查询，Apollo无法知道它将返回特定类型，直到该查询返回. cacheRedirects 提供了一种方式来表示此查询将返回此特定类型"，而无需首先触发查询.

The other consideration here is that outside of optionally passing in an instance of IntrospectionFragmentMatcher to your InMemoryCache, Apollo is not actually aware of what the schema is of the endpoint it queries. The types used by the cache in normalization are determined after a query is fetched using the __typename property. The whole point of cacheRedirects is to prevent a query from being fired if the item or items are already in the cache. However, given a particular query, Apollo has no way to know that it will return a particular type until after that query returns. cacheRedirects provides a way to say "this query will return this particular type" without ever having fired the query in the first place.

这篇关于何时使用Apollo的cacheRedirects?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！