GraphQL执行delete mutation后用refetchQueries重取数据是否正确？

你当前的实现是mutation执行后重新拉取后端数据的正确可用方式，可以满足删除帖子后同步最新列表的业务需求，同时也存在可优化的空间，以下是具体说明：

现有实现的合理性 #

• 你使用Apollo Client的refetchQueries配置项，指定了mutation执行成功后需要重新触发的查询，同时正确传入了分页所需的page和size变量，逻辑通顺
• awaitRefetchQueries: true的配置会保证所有重拉取的请求执行完成后，才会更新mutation的loading状态为false，符合绝大多数交互场景的预期
• onError回调也正确捕获了mutation执行的异常，方便调试定位问题

可优化的点 #

1. 语法层级修正 #

你贴出的代码缩进存在歧义，需要确认所有配置项（refetchQueries/awaitRefetchQueries/onError/variables）都和update平级，不要被错误嵌套到update的函数作用域内，否则会导致配置不生效。

2. refetchQueries 写法简化 #

你当前的refetchQueries用了函数返回数组的写法，如果你不需要根据mutation返回的结果动态调整要重拉取的查询和参数，直接传入数组即可，写法更简洁：

refetchQueries: [
  {
    query: FETCH_POSTS_QUERY,
    variables: { page, size },
  },
],

3. 可选的缓存更新方案（可替代 refetchQueries） #

如果你的业务场景不需要强一致的后端最新数据，也可以直接通过update函数操作Apollo本地缓存，删除对应的帖子记录，节省一次网络请求，实现方案参考如下：

const [deletePostFunc,{loading}]=useMutation(DELETE_POST,{
  update(proxy, result){
    // 读取缓存中当前页的帖子列表
    const cacheData = proxy.readQuery({
      query: FETCH_POSTS_QUERY,
      variables: { page, size }
    })
    // 过滤掉已删除的帖子
    const updatedPosts = cacheData.getPosts.filter(item => item.id !== post.id)
    // 将更新后的列表写回缓存
    proxy.writeQuery({
      query: FETCH_POSTS_QUERY,
      variables: { page, size },
      data: { getPosts: updatedPosts }
    })
  },
  onError(err){
    console.log(err?.graphQLErrors[0]?.extensions.errors)
  },
  variables:{postId:post.id}
})

两种方案的选择建议 #

• 如果业务对数据一致性要求高，或者存在多用户同时操作帖子的场景，保留你原有的refetchQueries方案更稳妥，不用自行处理复杂的缓存同步逻辑
• 如果追求更快的交互响应、减少无效网络请求，且只有当前用户会操作自己的帖子，用缓存更新方案性能更好

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