Vue-Query 中 queryKey 依赖检测的优化实践

在 Vue 生态中使用 TanStack Query（原 React Query）时，开发者可能会遇到一个关于 queryKey 依赖检测的特殊情况。本文将深入分析这个问题及其解决方案。

问题背景

当我们在 Vue 组合式 API 中使用 useQuery 时，通常会为 queryKey 传递一个响应式依赖。考虑以下常见场景：

const obj = reactive({ foo: undefined });
const query = useQuery({
  queryKey: ['demo', () => obj.foo],
  queryFn: () => fetch(`/api/${obj.foo}`)
});

这种情况下，ESLint 规则 @tanstack/query/exhaustive-deps 会错误地报告缺少依赖 obj.foo，尽管我们已经通过 getter 函数将其包含在 queryKey 中。

技术原理分析

这个问题源于 Vue 的响应式系统与 TanStack Query 依赖检测机制之间的微妙差异：

1. 响应式依赖追踪：Vue 的响应式系统通过 reactive/ref 创建响应式对象，依赖收集发生在 effect/computed 等场景
2. QueryKey 设计：TanStack Query 使用 queryKey 来唯一标识和缓存查询结果
3. 依赖检测机制：ESLint 规则会分析 queryFn/enabled 等选项中的依赖，确保它们都包含在 queryKey 中

解决方案比较

开发者可以采取以下几种方式解决这个问题：

方案一：使用 computed

const foo = computed(() => obj.foo);
const query = useQuery({
  queryKey: ['demo', foo],
  queryFn: () => fetch(`/api/${foo.value}`)
});

这是最符合 Vue 响应式理念的解决方案，通过 computed 显式声明依赖关系。

方案二：冗余声明（不推荐）

const query = useQuery({
  queryKey: ['demo', () => obj.foo, obj.foo],
  queryFn: () => fetch(`/api/${obj.foo}`)
});

虽然能通过检测，但造成了代码冗余，不推荐在生产环境使用。

方案三：等待官方修复

社区已经提交了修复该问题的 PR，未来版本中 getter 函数将被正确识别为依赖声明。

最佳实践建议

1. 优先使用 computed：在 Vue 环境中，computed 是最符合直觉的响应式声明方式
2. 保持依赖显式：确保 queryKey 包含所有在 queryFn 和 enabled 中使用的依赖
3. 关注版本更新：及时升级到修复该问题的版本，减少代码中的 workaround

总结

Vue 的响应式系统与 TanStack Query 的集成总体上是顺畅的，但在边缘情况下需要开发者理解两者的工作机制。通过本文的分析，开发者可以更好地处理这类依赖检测问题，写出更健壮的代码。

随着 Vue 和 TanStack Query 生态的不断发展，这类框架间的集成问题会逐渐减少，但理解其背后的原理仍然对解决实际问题大有裨益。