Redux Toolkit中RTK Query乐观更新与状态重置的注意事项

问题背景

在使用Redux Toolkit的RTK Query进行数据请求时，开发者经常会遇到需要实现乐观更新(optimistic update)的场景。乐观更新是指在请求发出前就假设请求会成功，先更新本地UI，等请求真正返回后再做最终确认或回滚。

典型问题表现

开发者在使用RTK Query的onQueryStarted和updateQueryData实现乐观更新时，发现isSuccess状态始终为false。具体表现为：

1. 移除onQueryStarted逻辑时，isSuccess能正常变为true
2. 添加乐观更新逻辑后，虽然网络请求成功且Redux状态已更新，但isSuccess却保持false
3. 类似问题也出现在执行resetApiState时

技术原理分析

RTK Query内部维护了一个请求状态机，isSuccess标志位的变化依赖于这个状态机的正常流转。当我们在onQueryStarted中执行某些操作时，可能会干扰这个状态机的正常工作：

1. 乐观更新时序问题：updateQueryData应该在请求完成前执行，但必须确保queryFulfilled被正确await
2. 状态重置干扰：在请求完成前调用resetApiState会清除所有请求状态，导致后续状态更新无法完成
3. 版本差异：较新版本的RTK Query对状态管理更加严格，旧版本中能容忍的一些时序问题在新版本中会暴露

解决方案

乐观更新正确写法

onQueryStarted: async ({ id, ...patch }, { dispatch, queryFulfilled }) => {
  const patchResult = dispatch(
    baseApi.util.updateQueryData("fetchLocationDetail", `${id}`, (draft) => {
      merge(draft, {
        address: patch.locationDetail.address,
        location: patch.locationDetail.location
      });
    })
  );
  try {
    await queryFulfilled; // 必须await请求完成
  } catch (error) {
    patchResult.undo(); // 请求失败时回滚
  }
}

状态重置的正确时机

对于需要在请求完成后重置状态的场景（如登出），应该：

1. 将状态重置操作放在请求完成后执行
2. 或者直接在组件中调用状态重置，而不是放在mutation的onQueryStarted中

// 组件中调用
const handleLogout = async () => {
  try {
    await logoutMutation().unwrap();
    dispatch(apiSlice.util.resetApiState());
  } catch (err) {
    console.error(err);
  }
};

最佳实践建议

1. 确保请求时序：始终在onQueryStarted中await queryFulfilled
2. 避免中间状态操作：不要在请求完成前执行可能干扰请求状态的操作（如resetApiState）
3. 分离关注点：将状态管理操作与数据获取操作分离
4. 错误处理：完善错误处理逻辑，确保在请求失败时能正确回滚

通过遵循这些原则，可以避免大多数与RTK Query状态管理相关的问题，确保isSuccess等状态标志能正确反映请求的实际状态。