本教程旨在解决React JS中RTK Query useLazyQuery实现无限滚动时API调用过于频繁的问题。我们将深入探讨如何利用API响应中的分页信息（如“是否有更多数据”标识）来精确控制数据请求，避免不必要的API调用，从而实现高效且性能优化的无限滚动体验，并提供详细的代码示例和注意事项。
理解无限滚动与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 Hookfunction 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 等性能优化手段，我们可以构建出高效、稳定且用户体验良好的无限滚动功能。
以上就是精通RTK Query无限滚动：优化API调用与停止策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1524355.html
微信扫一扫 
支付宝扫一扫 
