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

问题描述

我在互动中阅读了文档与缓存的数据，虽然我了解了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 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.

那是为什么?

为清楚起见，将示例粘贴到文档中

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转换为其中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来教导"阿波罗如何查找可能已经在缓存中的数据.这有效地复制了通常驻留在服务器上的一些业务逻辑，但有助于我们避免对服务器的额外调用.

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屋！