Redux Toolkit中transformErrorResponse的正确使用方式

在使用Redux Toolkit的RTK Query进行API调用时，错误处理是一个非常重要的环节。本文将通过一个实际案例，深入探讨如何正确使用transformErrorResponse来处理API错误，特别是会话过期(403错误)的场景。

问题背景

在开发过程中，我们经常需要处理API返回的各种错误状态。其中，403状态码通常表示会话过期或权限不足，这时我们需要将用户重定向到登录页面。一位开发者在实现这个功能时遇到了问题：当API返回403错误时，isRejectedWithValue判断没有生效，导致无法触发登出逻辑。

核心问题分析

问题的根源在于transformErrorResponse的使用方式。开发者原本的代码如下：

export const transformErrorResponse = (response: { status: number, data: { error: string } }) => response.data.error;

这种实现方式直接将错误响应转换为错误消息字符串，导致丢失了原始响应中的状态码等重要信息。当RTK Query处理错误时，由于transformErrorResponse返回的不是完整的错误对象，isRejectedWithValue无法正确识别这是一个带有值的拒绝操作。

正确解决方案

要正确处理API错误并保留状态码信息，我们应该修改transformErrorResponse的实现：

export const transformErrorResponse = (response) => {
  return {
    status: response.status,
    message: response.data?.error || 'Unknown error'
  };
};

这种实现方式保留了原始响应的状态码，同时提取了错误消息。这样，在中间件中我们就可以同时访问状态码和错误消息：

if (isRejectedWithValue(action)) {
  if (action.payload?.status === 403) {
    // 处理会话过期逻辑
  }
}

错误处理最佳实践

1. 保持错误对象结构一致：无论API返回什么类型的错误，都应该转换为统一的结构，方便前端处理。

2. 保留原始错误信息：至少应该保留状态码和错误消息这两个关键信息。

3. 全局错误处理中间件：使用RTK Query的中间件来处理通用错误逻辑，如会话过期、权限不足等。

4. 组件级错误处理：对于特定业务逻辑的错误，应该在组件中处理。

会话过期处理完整示例

export const rtkQueryErrorLogger: Middleware =
  (api: MiddlewareAPI) => (next) => (action) => {
    if (isRejectedWithValue(action)) {
      if (action.payload?.status === 403) {
        // 重置API状态
        api.dispatch(baseApi.util.resetApiState());
        // 清除用户登录状态
        api.dispatch(setCurrentAccount({ account: null }));
        // 显示错误提示
        toast.error('会话已过期，请重新登录');
      } else {
        // 处理其他错误
        const message = action.payload?.message || '请求失败';
        toast.error(message);
      }
    }
    return next(action);
  };

总结

正确处理API错误是前端开发中的重要环节。通过合理使用transformErrorResponse和中间件，我们可以实现统一的错误处理机制，提高代码的可维护性和用户体验。特别是在处理会话过期等全局性错误时，这种集中处理的方式显得尤为重要。

记住，transformErrorResponse的目的是转换错误响应，而不是简化它。保留必要的错误信息，才能在后期的错误处理中做出正确的判断和操作。