为什么我们需要`cacheRedirects`? [英] Why do we need `cacheRedirects` at all?

问题描述

我阅读了关于 interacting 的文档使用缓存数据，虽然我了解 cacheRedirects 的工作原理，但我有点困惑为什么首先需要它.这是我问另一个问题的部分原因:是否Apollo 客户端在 React 中缓存嵌套对象?

I read the docs on interacting with cached data and while I understand how cacheRedirects works, I'm a bit confused why it is needed in the first place. This is part of the reason why I asked this other question: Does the Apollo client cache nested objects in React?

我们知道数据很可能已经在客户端缓存中，但是因为它是通过不同的查询请求的，Apollo 客户端不知道这一点.

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.

这是为什么?

为了清楚起见，复制粘贴文档中的示例:

Copy-pasting the example in the docs, for clarity:

query ListView {
  books {
    id
    title
    abstract
  }
}

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

推荐答案

Apollo 将收到的数据缓存在 规范化 方式.

Apollo caches the data it receives in a normalized manner.

如果您的 ListView 返回如下数据:

If your ListView returns data like:

{
  "data": {
    "books": [
      {
        "id": 1,
        "title" "ABC",
        "__typename": "Book"
      },
      {
        "id": 2,
        "title" "DEF",
        "__typename": "Book"
      }
    ]
  }
}

每本书将根据其 id 和 __typename (Book:1, Book:2 等).这个特定的缓存键列表然后与 books 根字段相关联.如果您再次请求 books，Apollo 将看到它已经在缓存中具有该查询，并将根据键列表重新创建结果.

each book will be stored in the cache under a key based on its id and __typename (Book:1, Book:2, etc.). This particular list of cache keys is then associated with the books root field. If you request books again, Apollo will see it has that query in the cache already and will recreate the result based on the list of keys.

如果 books 接受一些参数，那么每组参数都被视为不同的缓存条目.books(onSale: true) 可能返回与 books(subject: "Computer Science") 不同的书籍集.每组缓存键都单独存储.如果您先运行第一个查询，然后运行第二个，则第二个将是缓存未命中并且仍会命中服务器.

If books takes some arguments, then each set of arguments is treated as a different cache entry. books(onSale: true) might return a different set of books than books(subject: "Computer Science"). Each set of cache keys is stored separately. If you run the first query and then the second, the second will be a cache miss and will still hit the server.

类似地，您可以使用一些参数并返回一本书的查询，例如 book(id: 1).但是，在所有这些示例中，Apollo 并不理解"参数 id 和 onSale 是什么.这些参数与返回结果的关系是业务逻辑的一部分.Apollo知道"的是，给定这个查询和这组参数，你会得到这个特定的对象或对象数组.

Similarly, you can have a query that takes some arguments and returns a single book, like book(id: 1). In all these examples, though, Apollo doesn't "understand" what the arguments id and onSale are. How these arguments relate to the returned results is part of your business logic. All Apollo "knows" is that given this query and this set of arguments, you get this particular object or array of objects.

作为一个人，我可以通过命名像 book(id: 2) 这样的查询来推断 id 为 2 的一本书.但是，像 Apollo 这样的库无法准确推断出该信息——它如何猜测字段的正确类型或返回单个对象而不是对象数组?就此而言，它如何推断 id: 2 转换为Book where id = 2"?毕竟，实际参数可以有多种形式:book(identifier: 2)、book(filter: { id: 2 }) 等.

As a human, I can infer from naming that a query like book(id: 2) returns a single book with the id of 2. But there's no way for a library like Apollo to accurately infer that information -- how could it guess the correct type for the field or that it returns a single object instead of an array of objects? For that matter, how can it infer that id: 2 translates to "Book where id = 2"? After all, the actual arguments could look any number of ways: book(identifier: 2), book(filter: { id: 2 }), etc.

所以我们使用 cacheRedirects 来教" Apollo 如何查找可能已经在我们缓存中的数据.这有效地复制了通常驻留在服务器上的一些业务逻辑，但有助于我们避免对服务器的额外调用.

So we use cacheRedirects to "teach" Apollo how to look up data that may already be in our cache. This effectively duplicates some of the business logic that normally resides on the server, but helps us avoid an additional call to the server.

这篇关于为什么我们需要`cacheRedirects`?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！