在React Native中用RTK Query Hooks预取数据是否为反模式？

场景回顾 #

在React Native项目的Bottom Tab Navigation中，你的实现逻辑如下：

• 在导航栈初始化文件MainNavigator.tsx中直接调用useGetLatestEventsQuery钩子（不使用其返回的data、isLoading等状态），以此预取未挂载的Events和Favorites屏幕所需数据
• Tickets作为初始屏幕，直接调用对应钩子获取数据，无需预取
• 在Events和Favorites屏幕中，再次调用useGetLatestEventsQuery钩子，初始设置skip: true，后续通过refetch方法实现屏幕刷新时重新请求数据

是否属于反模式？ #

这种实现不算严格意义上的反模式，但存在多处不合理的设计，会带来潜在问题：

1. 预取逻辑的意义被浪费 #

RTK Query的核心特性之一是基于查询键的自动缓存机制。如果你在MainNavigator和子屏幕中使用的是同一个查询键调用useGetLatestEventsQuery，预取的请求会被存入缓存，但子屏幕设置skip: true后，会直接跳过缓存读取，反而要手动调用refetch重新请求，完全浪费了预取的价值。如果查询键不一致，还会发起重复请求，造成资源冗余。

2. 组件职责越界 #

MainNavigator的核心职责是定义导航结构、管理路由跳转逻辑，现在额外承担了业务数据预取的工作，违反了单一职责原则。这会让导航组件与业务数据逻辑耦合，后续修改导航结构或数据请求逻辑时，维护成本会显著提升。

3. 无效请求浪费资源 #

MainNavigator会在App启动时就完成渲染，此时发起的预取请求，可能用户根本不会切换到Events或Favorites屏幕，这就造成了不必要的网络请求，浪费用户的带宽和设备性能。

更合理的优化方案 #

• 按需预取，利用prefetchQuery：监听Bottom Tab的tabPress事件，当用户点击Events或Favorites标签时，再调用RTK Query的prefetchQuery方法预取数据，让请求时机更贴合用户行为，避免无效请求。
• 子屏幕直接复用缓存：去掉子屏幕中skip: true的设置，直接调用useGetLatestEventsQuery。如果预取的缓存有效，RTK Query会自动返回缓存数据，同时还能借助其自动重新验证机制，在缓存过期时自动刷新数据，无需手动调用refetch。
• 抽离预取逻辑：把数据预取的逻辑封装到自定义钩子或独立的服务层中，让MainNavigator回归导航职责，降低代码耦合度。

内容的提问来源于stack exchange，提问作者Damilare Gabriel Idowu