理解 query 和 transformResponse 的局限性
在使用 rtk-query 构建数据获取层时，我们通常会定义 endpoints，其中包含 query 或 mutation 方法。这些方法内部可以进一步定义 query 函数来构造请求参数，以及 transformresponse 函数来处理响应数据。然而，query 和 transformresponse 函数的设计初衷是专注于请求和响应的直接转换，它们并没有直接提供访问 redux store 完整状态的能力。
例如，在以下场景中，如果我们需要 Redux Store 中的某个值（如 salt）来构建请求体或解密响应数据，query 和 transformResponse 将无法直接满足需求：
import { createApi } from '@reduxjs/toolkit/query/react'
import customFetchBase from './customFetchBase.js'
import { setUserInfo, setUserPermissions } from '../features/userSlice.js'
import { aesDEC } from 'src/util/public.util.js'
export const authApi = createApi({
reducerPath: 'authApi',
baseQuery: customFetchBase,
endpoints: builder => ({
getUser: builder.mutation({
query: () => ({
url: '/Account/Login/GetUserInfo',
method: 'POST',
body: {
RequestVerificationToken: salt // 此处需要 Redux Store 中的 salt
}
}),
transformResponse: response => {
return aesDEC(response.data, salt); // 此处也需要 Redux Store 中的 salt
},
}),
})
export const { useGetUserMutation } = authApi在上述代码中，无论是 query 函数的 body 还是 transformResponse 函数的 aesDEC 调用，都试图访问一个名为 salt 的变量，而这个变量预期来源于 Redux Store。由于 query 和 transformResponse 的作用域限制，它们无法直接获取到 Redux Store 的状态。
解决方案：使用 queryFn 访问 Redux Store
为了克服 query 和 transformResponse 的局限性，RTK-Query 提供了 queryFn 选项。queryFn 允许开发者完全自定义查询逻辑，并且其函数签名提供了访问 Redux Store 状态的 api 对象。
queryFn 的函数签名如下： async (arg, api, extraOptions, baseQuery) => { ... }
其中，api 对象是关键，它包含一个 getState 方法，通过 api.getState() 即可获取当前的 Redux Store 状态。
queryFn 参数详解：
- arg: 传递给端点的参数。
- api: 包含 dispatch 和 getState 等方法的对象，用于与 Redux Store 交互。
- api.getState(): 获取 Redux Store 的当前状态快照。
- api.dispatch(): 派发 Redux Action。
- extraOptions: 传递给 createApi 或 endpoint 的额外选项。
- baseQuery: 定义在 createApi 中的 baseQuery 函数，可以在 queryFn 内部手动调用，以执行实际的网络请求。
改造示例：在 queryFn 中获取 salt
现在，我们将之前的示例代码使用 queryFn 进行改造，以实现在请求和响应处理中访问 Redux Store 中的 salt 值。
import { createApi } from '@reduxjs/toolkit/query/react'
import customFetchBase from './customFetchBase.js'
import { setUserInfo, setUserPermissions } from '../features/userSlice.js'
import { aesDEC } from 'src/util/public.util.js'
export const authApi = createApi({
reducerPath: 'authApi',
baseQuery: customFetchBase,
endpoints: builder => ({
getUser: builder.mutation({
queryFn: async (arg, api, extraOptions, baseQuery) => {
// 1. 通过 api.getState() 访问 Redux Store 状态
const state = api.getState();
// 假设 salt 存储在 userSlice 的某个位置，例如 state.user.salt
const salt = state.user.salt; // 请根据实际 Redux Store 结构调整路径
try {
// 2. 使用获取到的 salt 构建请求体，并调用 baseQuery 执行请求
const { data, error } = await baseQuery({
url: '/Account/Login/GetUserInfo',
method: 'POST',
body: {
RequestVerificationToken: salt
}
});
// 3. 处理 baseQuery 的响应
if (error) {
return { error }; // 如果有错误，直接返回错误
}
// 4. 使用获取到的 salt 解密响应数据
const decryptedData = aesDEC(data, salt);
return { data: decryptedData }; // 返回处理后的数据
} catch(error) {
// 5. 捕获并返回任何运行时错误
return { error };
}
},
}),
})
});
export const { useGetUserMutation } = authApi代码解析：
- queryFn: async (arg, api, extraOptions, baseQuery) => { ... }: 我们将 query 和 transformResponse 的逻辑合并到了一个 async 函数 queryFn 中。
- const state = api.getState();: 这是获取 Redux Store 状态的关键步骤。api 对象作为 queryFn 的第二个参数传入，其 getState() 方法返回当前的 Redux Store 状态树。
- const salt = state.user.salt;: 通过 state 对象，我们可以按照 Redux Store 的实际结构访问到所需的 salt 值。请务必根据您的 reducer 结构调整 salt 的访问路径。
- await baseQuery(...): 在 queryFn 内部，我们手动调用了传入的 baseQuery 函数来执行实际的网络请求。这使得我们可以在请求发出之前，利用 Redux 状态动态地构建请求参数。
- 错误处理: queryFn 提供了完全的控制权，这也意味着我们需要手动处理请求的成功和失败。baseQuery 返回一个包含 data 或 error 属性的对象。我们通过 if (error) 来判断请求是否成功，并返回相应的 { error } 或 { data }。
- 响应转换: 原本在 transformResponse 中进行的 aesDEC(response.data, salt) 操作，现在直接在 queryFn 内部完成，同样利用了从 Redux Store 获取的 salt。
注意事项与最佳实践
- 完全控制与责任: queryFn 提供了极大的灵活性，但这也意味着您需要承担更多的责任，包括手动调用 baseQuery、处理错误、以及进行数据转换。
- 路径准确性: 确保 api.getState() 后访问 Redux 状态的路径 (state.user.salt) 是准确的，否则会导致 undefined 错误。
- 异步操作: queryFn 通常是一个 async 函数，因为网络请求是异步的。请确保正确使用 await 和 try...catch 进行异步操作和错误处理。
-
何时使用 queryFn:
- 当您的请求参数或响应处理逻辑依赖于 Redux Store 中的状态时。
- 当您需要执行复杂的请求前置逻辑（如条件请求、动态 URL 构建等）。
- 当您需要完全自定义请求和响应的生命周期，包括手动调用 baseQuery 之外的其他逻辑时。
-
何时使用 query / transformResponse:
- 对于大多数简单的 CRUD 操作，如果请求参数和响应转换不依赖于 Redux Store 状态，或者依赖可以通过 arg 传入，那么 query 和 transformResponse 仍然是更简洁、更推荐的选择。
总结
通过 queryFn 选项，RTK-Query 提供了一个强大而灵活的机制，允许开发者在端点内部访问 Redux Store 的状态。这对于需要动态构建请求、根据用户权限调整请求或在响应处理中利用 Store 数据的复杂场景至关重要。虽然 queryFn 引入了更多的手动控制，但它也赋予了我们处理高级数据交互逻辑的能力，是 RTK-Query 高级用法中不可或缺的一部分。正确地运用 queryFn，能够显著提升 RTK-Query 的应用范围和灵活性。
