理解无限滚动与RTK Query useLazyQuery的挑战
在react应用中实现无限滚动（infinite scrolling）是一种常见的用户体验模式，它允许用户在滚动到页面底部时自动加载更多内容。rtk query的uselazyquery hook非常适合这种场景，因为它提供了手动触发数据请求的能力。然而，不当的实现方式可能导致api调用过于频繁，尤其是在用户快速滚动或滚动事件未被有效节流时。
原始的实现尝试中，存在以下几个问题：
- API调用控制不足： getImages(pageNumber) 在 pageNumber 变化时触发，但没有明确的条件来判断是否已加载所有数据。
- 数据合并时机不当： setData((prev) => [...new Set([...prev, ...images])]); 依赖于 images 变量，而 images 是 useLazyGetImagesQuery 的返回值，它在API请求完成后才更新。将数据合并逻辑放在与 getImages 相同的 useEffect 中，可能导致 images 尚未更新时就尝试合并旧数据。
- 滚动事件触发频繁： handleScroll 函数在每次滚动时都会被调用，如果没有节流（throttle）或防抖（debounce）处理，即使在 imageLoading === false 的条件下，也可能在短时间内触发多次 setPageNumber。
- 停止条件缺失： 最核心的问题是，当所有数据都已加载完毕时，缺少一个机制来停止 setPageNumber 的递增，从而避免无意义的API请求。
核心解决方案：利用API分页信息控制加载
解决上述问题的关键在于，后端API通常会提供关于分页状态的信息，例如一个布尔值指示“是否有下一页”（hasNextPage）或“是否已到达最后一页”（isLastPage），或者返回一个 nextCursor 等。我们应该利用这些信息来精确控制前端的加载行为。
1. RTK Query Endpoint 配置
首先，我们需要在RTK Query的endpoints中定义我们的查询，并利用transformResponse来处理API响应，提取出我们所需的分页信息（例如 hasMore）。
// src/services/api.js (或者你的 RTK Query service 文件)
import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';
export const imageApi = createApi({
reducerPath: 'imageApi',
baseQuery: fetchBaseQuery({ baseUrl: 'https://your-api.com/' }), // 替换为你的API地址
endpoints: (builder) => ({
getImages: builder.query({
query: (page = 1, limit = 10) => `images?page=${page}&limit=${limit}`,
// transformResponse 用于在数据到达组件前进行预处理
transformResponse: (response) => {
// 假设API响应结构为 { data: [...images], pagination: { currentPage, totalPages, hasNextPage } }
return {
images: response.data,
hasMore: response.pagination.hasNextPage, // 从API响应中获取是否有更多数据
};
},
}),
}),
});
export const { useLazyGetImagesQuery } = imageApi;2. 组件中的实现
接下来，在React组件中，我们将结合useLazyGetImagesQuery、useState和useEffect来构建一个健壮的无限滚动逻辑。
import React, { useState, useEffect, useCallback } from 'react';
import { useLazyGetImagesQuery } from './services/api'; // 导入你的API Hook
function ImageGallery() {
// useLazyGetImagesQuery 返回一个触发函数和查询状态
const [getImages, { data: imagesResponse, isLoading, isFetching, error }] = useLazyGetImagesQuery();
// 存储所有已加载的图片数据
const [allImages, setAllImages] = useState([]);
// 当前请求的页码
const [pageNumber, setPageNumber] = useState(1);
// 标识是否还有更多数据可以加载
const [hasMore, setHasMore] = useState(true); // 初始假设有更多数据
// 1. 触发API请求的Effect
useEffect(() => {
// 只有当hasMore为true时才发起请求，避免无意义的API调用
if (hasMore) {
getImages(pageNumber);
}
}, [pageNumber, hasMore, getImages]); // 依赖项包含getImages以避免linter警告
// 2. 处理API响应并更新数据和hasMore状态的Effect
useEffect(() => {
if (imagesResponse && imagesResponse.images) {
setAllImages((prev) => {
const newImages = imagesResponse.images;
// 使用Set来确保图片唯一性，防止API返回重复数据
return Array.from(new Set([...prev, ...newImages]));
});
// 根据API响应更新hasMore状态
setHasMore(imagesResponse.hasMore);
}
}, [imagesResponse]); // 仅当imagesResponse变化时执行
// 3. 滚动事件处理函数
// 使用 useCallback 优化，防止每次组件渲染都重新创建函数，导致 useEffect 频繁重新注册事件监听器
const handleScroll = useCallback(() => {
const { scrollTop, clientHeight, scrollHeight } = document.documentElement;
// 判断是否滚动到页面底部（例如，距离底部10%的位置）
// 并且当前没有正在进行的数据请求 (isFetching)
// 并且还有更多数据可以加载 (hasMore)
if (
scrollTop + clientHeight >= scrollHeight * 0.9 && // 90% 阈值，可根据需要调整
!isFetching && // 使用 isFetching 更准确地判断当前是否有请求在进行
hasMore
) {
setPageNumber((prevPageNumber) => prevPageNumber + 1);
}
}, [isFetching, hasMore]); // 依赖项：isFetching 和 hasMore
// 4. 注册和清理滚动事件监听器
useEffect(() => {
window.addEventListener('scroll', handleScroll);
return () => {
window.removeEventListener('scroll', handleScroll);
};
}, [handleScroll]); // 依赖项：handleScroll
// 渲染部分
return (
);
}
export default ImageGallery;
注意事项与优化
-
isLoading vs isFetching:
- isLoading: 仅在查询的第一个请求生命周期内为 true。
- isFetching: 在任何时候只要有请求在进行就为 true，包括后续的刷新或分页请求。
- 对于无限滚动，isFetching 更适合用来判断当前是否有请求正在进行，以防止在请求尚未完成时触发新的分页请求。
-
滚动事件节流/防抖： 尽管 !isFetching 和 hasMore 已经提供了很好的控制，但在高频率的滚动事件中，handleScroll 依然会被频繁调用。为了进一步优化性能，可以对 handleScroll 函数进行节流（throttle）处理。
import throttle from 'lodash/throttle'; // 或者自己实现一个节流函数 // ...在组件内部 const throttledHandleScroll = useCallback( throttle(() => { const { scrollTop, clientHeight, scrollHeight } = document.documentElement; if ( scrollTop + clientHeight >= scrollHeight * 0.9 && !isFetching && hasMore ) { setPageNumber((prevPageNumber) => prevPageNumber + 1); } }, 200), // 每200毫秒最多执行一次 [isFetching, hasMore] ); useEffect(() => { window.addEventListener('scroll', throttledHandleScroll); return () => { window.removeEventListener('scroll', throttledHandleScroll); throttledHandleScroll.cancel(); // 清理节流函数 }; }, [throttledHandleScroll]); 错误处理： 在组件中添加对 error 状态的处理，向用户展示友好的错误信息。
用户体验： 在加载更多数据时，显示一个“加载中...”的指示器。当所有数据加载完毕时，显示一个“所有内容已加载”的提示，提升用户体验。
滚动阈值： scrollHeight * 0.9 这个阈值可以根据实际需求进行调整。有些场景可能希望更早地加载数据（例如 0.8），有些则希望用户更接近底部再加载（例如 0.95）。
总结
通过上述优化方案，我们成功地解决了RTK Query useLazyQuery在无限滚动中API调用过于频繁的问题。核心思想是利用后端API提供的分页信息（如 hasMore）来精确控制前端的加载逻辑，确保只在需要且有更多数据时才发起新的API请求。结合 isFetching 状态管理和 useCallback、throttle 等性能优化手段，我们可以构建出高效、稳定且用户体验良好的无限滚动功能。
