我有一个getTracks
查询,它将获取跟踪数据,并采取一些参数进行排序/过滤(限制,偏移,搜索,排序,顺序)。不幸的是,Apollo单独缓存所有这些,因此当在一个视图中删除项目时,用户更改排序顺序,并且删除的项目仍然存在(因为它在缓存中用于不同的参数集)。
这是getTracks
查询以及相关的输入类型(在我的服务器端AppSync架构中):
input SelectOptions {
limit: Int
offset: Int
sort: String
order: String
search: String
}
type Query {
getTracks(options: SelectOptions): TrackList!
}
type TrackList {
total: Int!
items: [Track!]!
}
在Vue客户端中,查询如下所示:
query GetTracks($options: SelectOptions) {
getTracks(options: $options) {
total
items {
id
name
runtime
createdAt
metadata {
trackNum
trackName
artistName
albumName
year
}
}
}
}
第一次显示表时,项目加载并显示正常(默认排序顺序为createdAt / desc)。如果我按createdAt / asc排序,则会获取网络请求以获取结果,并且它们显示正常。现在,如果我删除其中一条记录,然后再次按createdAt / desc排序,则会显示已删除的项目,因为它正在从缓存中提取它。
即使查询具有不同的参数,Apollo中也没有办法让它智能地通过并从缓存中删除(或添加/修改)项目吗?我确实尝试了@connection
指令as documented here,但它只是这样做,所以排序表没有任何效果(它根本不会从服务器获取)。
我完全陷入困境,并准备完全禁用缓存,因为它似乎不适用于真实场景。如何保留默认的cache-and-network
策略,但在数据更改时让我的表行为正常?
不幸的是,this issue has been brought up before并没有一个很好的现有解决方案。最大的问题是客户端和缓存都没有公开任何方法来获取给定查询的所有请求 - 如果你有这些信息,你可以迭代请求并适当地更新缓存。
你能做的第二件事就是利用apollo-link-watched-mutation。该链接使我们能够有效地识别每个突变需要更新的一个或多个查询,但它使用操作名称来识别查询(以及哪些突变应该触发它们)。这样,您甚至不需要知道相关变量来更新查询 - 您只需要一致地命名您的操作。
new WatchedMutationLink(
cache,
{
SaveTodo: {
TodoList: ({ mutation, query }) => {
// update logic here
}
}
}
)
这种方法的一个缺点是您无法在每个组件的基础上定义update
逻辑。但是,您也可以通过使用不同名称的突变来绕过该限制。