修改或添加条目后如何更新Apollo Client过滤列表？

关于后端返回「是否可见」的做法 #

这种方式完全可行，而且属于比较直接的解决方案，不算非常规操作。毕竟后端掌握完整的过滤逻辑，能精准判断条目是否符合当前查询的过滤条件。前端拿到这个标记后，处理缓存就很清晰：

• 新增条目：如果标记为可见，就用writeFragment把它加入对应查询的缓存列表；不可见的话直接忽略，不更新列表缓存。
• 修改条目：先从缓存列表里找到旧条目，要是新标记显示可见，就替换成新条目；不可见的话，把它从列表缓存里移除就行，同时别忘了更新单个条目的缓存——毕竟其他查询可能还会用到它。

这种方法的最大优点就是逻辑简单，前端不用关心过滤规则细节，完全依赖后端的判断，不容易出错。

无需重新拉取数据的其他方案 #

1. 后端返回轻量过滤规则元数据 #

如果不想每次都返回「是否可见」标记，可以让后端把当前查询对应的过滤规则核心信息返回给前端，比如过滤关键词、匹配模式（包含/完全匹配等）。前端拿到后，自己判断新条目或修改后的条目是否符合条件，再处理缓存。

• 举个例子：查询时后端除了返回列表，还返回filterInfo: { keyword: "张三", matchType: "contains" }，前端就可以用这个规则去校验条目名称。
• 但要注意：如果过滤逻辑复杂（比如多字段组合、正则匹配、数据库层面的模糊查询），前端很难完全复刻后端的判断逻辑，容易出现前后端不一致的情况，这种场景就不适合用这个方法。

2. 用mutation的update函数结合缓存读取 #

在mutation的update回调里，先读取当前查询的缓存数据和对应的过滤变量，然后手动处理列表：

• 新增场景：先拿到缓存里的当前列表，判断新条目是否符合过滤条件（能复刻后端逻辑的话），符合就添加到缓存列表。
• 修改场景：找到缓存列表里的旧条目，判断修改后的新条目是否符合条件，符合就替换，不符合就从列表里移除。
• 同样，这个方法的前提是前端能准确复刻后端的过滤逻辑，复杂场景慎用。

3. 用cache.modify做精准缓存操作 #

比起writeFragment，cache.modify能更灵活地修改缓存中的列表数据：

• 新增时的代码示例：

  cache.modify({
    fields: {
      nameList(existingNames = [], { readField }) {
        // 这里要么用后端返回的可见标记，要么自己判断
        const isVisible = /* 判断逻辑 */;
        if (isVisible) {
          return [...existingNames, newItem];
        }
        return existingNames;
      }
    }
  });
  

• 修改时的代码示例：

  cache.modify({
    fields: {
      nameList(existingNames = [], { readField }) {
        const isVisible = /* 判断修改后的条目是否符合过滤条件 */;
        return existingNames.map(item => 
          readField('id', item) === updatedItem.id 
            ? (isVisible ? updatedItem : null) 
            : item
        ).filter(Boolean); // 把不符合条件的条目过滤掉
      }
    }
  });
  

• 核心还是得判断条目是否可见，所以要么前端能复刻逻辑，要么还是得靠后端返回的标记。

总结 #

最后给你梳理下：

• 后端返回「是否符合当前过滤条件」的标记，是最稳妥省心的方案，尤其是过滤逻辑复杂的场景，能保证前后端判断一致，避免缓存和实际数据不一致的问题。
• 如果过滤逻辑很简单（比如只是关键词包含），也可以自己在前端写判断逻辑，用Apollo的cache.modify或者mutation的update函数处理缓存，不用麻烦后端加字段。
• 上述方案都能做到不用重新拉取数据，既省流量又不影响用户体验。

内容的提问来源于stack exchange，提问作者Moritz