Implementing infinite scroll with RTK Query #1163
-
|
Hey all! First off, great work on RTK Query! My team is stoked to start using it. I saw that there isn't built-in support for infinite scrolling yet, but I was wondering if there was any recommended pattern for implementing this ourselves in the meantime. I was thinking we could build a custom hook that wraps useQuery and aggregates the results into an array in local state, but I'm unsure about the specifics. function useInfiniteContactSearchQuery({ query, page }: { query: string; page: number ) {
const [results, setResults] = useState<Array<Contact>>([]);
const result = useContactSearchQuery({ query: query, page: page });
// ...somehow append result.data to results when we fetch a new page here
}Or is there a better way to handle this within Edit: Sorry, just found this discussion which answers my question: https://stackoverflow.com/questions/67909356/is-there-any-way-to-fetch-all-the-responses-stored-in-api-slice-rtk-query |
Beta Was this translation helpful? Give feedback.
Replies: 35 comments 149 replies
-
Status Update, 2024-10-27We're now actively working on a PR to implement official infinite query support! Please see that PR for progress updates, and try it out and give us feedback! Original AnswerCopying my answer from there over here so that people find it more easily 🙂 (also, here would be a generally better place to further discuss any upcoming problems since SO doesn't realle encourage much discussion) I think most implementations overcomplicate the problem of "infinite scroll" by a lot.
Since we are lazy and do not want to track which direction we're scrolling to, just assume
Also let's assume the query returns a response like {
offset: 50,
items: [...]
}So assuming one page is big enough to contain all the data for a screen, we'd end up with something like const currentPage = // something calculated from ScrollPosition
const lastResult = usePageQuery(currentPage - 1, { skip: currentPage === 1 }) // don't fetch pages before 0
const currentResult = usePageQuery(currentPage)
const nextResult = usePageQuery(currentPage + 1)
const combined = useMemo(() => {
const arr = new Array(pageSize * (currentPage + 1))
for (const data of [lastResult.data, currentResult.data, nextResult.data]) {
if (data) {
arr.splice(data.offset, data.items.length, ...data.items)
}
}
return arr
}, [pageSize, currentPage, lastResult.data, currentResult.data, nextResult.data])
// work with `combined` hereSince requests that are not referenced by your component, will stay in the store for 60 seconds, the user can scroll up quickly through many pages without further requests - but also, data that will probably never scrolled to again will be removed from the cache and simply re-fetched when necessary. edit from Mark, 2023-02-14 Pasting in Lenz's commentary on why we don't currently ship infinite query support out of the box in RTKQ:
My own thoughts: I think it's clear from this thread that there is a real desire to have some kind of built-in support around infinite queries in RTKQ, and given that it is something I would like us to try to cover at some point. But, given all the other concerns we're juggling right now, it just isn't something we have time to prioritize or focus on atm. At a minimum, it might be nice if we could comb through this page and list some of the specific recipes discussed here in our docs. But again, that requires time and effort and prioritization, and we're very limited on that front. It would be very helpful if folks from the community could pitch in with that. We welcome all attempts at useful contributions, and we'd love to have folks help improve our docs or contribute better functionality! |
Beta Was this translation helpful? Give feedback.
-
|
@Elendil00 Usually you would be using a "windowing" library like https://github.com/bvaughn/react-window to calculate the actual viewport height and that - and also give you the right positioning for every page. |
Beta Was this translation helpful? Give feedback.
-
In fact I tried using bx-stable-infinite-scroll and it does exactly what i need, i plugged the scroll listener to the window instead of a div container ref. In my case UX is far better if i can scroll from anywhere in the window + the scrollbar is on the far right of the window that don't disturb from reading content. I am just facing a scrollbar issue after my changes to have the scroll listener on the window. Once the bottom page reached, the scrollbar stay stuck at the bottom... In fact, i use bootstrap with 3 columns (left sidebar/body/right sidebar) and it appears that if i remove the left sidebar column, the window scrollbar have the right behavior (seems related to the lg-3 style that set width=25%, if i remove this style for testing purpose, the scrollbar has the expected behavior... so weird). React-bootstrap & Bootstrap are up to date. I also made tests with mobile/tablet and it's ok. It reminds me why i don't like UI stuff :D Just trolling, it is likely that i miss some CSS skills & understanding in the tools i am using ! |
Beta Was this translation helpful? Give feedback.
-
|
If you change the whole array of data, it will be the same length and the actual viewport height won't change either. You might want to fill array with empty values (that part which should be removed from cache) so your current data would have correct index (visisble index in react window like software) which you could use as a landmark to calculate currentPage. I assume that @phryneas do exactly that in his example. update: Also, I found out that if you do this you'll to find a way to preserve the length of data arrays on back scrolling because as soon as you will go back the size of array will change and you will be thrown at random place while changing the ‘page’ based on your scrolling position |
Beta Was this translation helpful? Give feedback.
-
|
The method @phryneas offered is great. But I wonder how it might work in case of cursor logic. If we don't use pages we actually lose offset data and find a need to store cursors in some kind of array (for example in redux entity store) so we can bind currentPage variable to cursors. Probably, in such cases we'd better use something offered later (method with pages) querying cursors in a parent component and then pass it to children (pages) |
Beta Was this translation helpful? Give feedback.
-
|
I am having trouble implementing this with React Native FlatList. I thought that using |
Beta Was this translation helpful? Give feedback.
-
|
I think using cache management utils would be one of a good solution. https://redux-toolkit.js.org/rtk-query/api/created-api/cache-management-utils |
Beta Was this translation helpful? Give feedback.
-
|
Since this spans over multiple cache entries, I would recommend doing it at use site. |
Beta Was this translation helpful? Give feedback.
-
|
I use that solution with useSelector: import { useEffect, useMemo, useState } from "react";
import { useAppSelector } from "./useStore";
import get from "lodash/get";
const isStringIncludesAllOfArr = (string: string, arr: string[]) =>
arr.every((item: string) => string.includes(item));
export function useCombinedResults<ResultsType>(
endpointName: string | undefined,
includes: string[]
): ResultsType[] {
const [selectorEndpoint, setSelectorEndpoint] = useState("");
useEffect(() => {
if (endpointName) {
setSelectorEndpoint(endpointName);
}
}, [endpointName]);
const queries = useAppSelector((state) => state.handbookApi.queries);
const combinedResults = useMemo(() => {
let results: ResultsType[] = [];
if (selectorEndpoint.length) {
for (const key in queries) {
if (isStringIncludesAllOfArr(key, [...includes, selectorEndpoint])) {
const addarr = get(queries[key], "data.results") || [];
results = [...results, ...addarr];
}
}
}
return results;
}, [selectorEndpoint, includes, queries]);
return combinedResults;
}const { data, error, isLoading, endpointName, originalArgs } =
useGetMyDataListQuery(
{ offset, limit, search },
{ skip: offset > maxOffset }
);
const combinedResults = useCombinedResults<MyDataResultsType>(endpointName, [
`"search":"${search}"`,
]); |
Beta Was this translation helpful? Give feedback.
-
|
I forgot about caching policy |
Beta Was this translation helpful? Give feedback.
-
|
Any plan to support this natively? @phryneas |
Beta Was this translation helpful? Give feedback.
-
|
I think it's good to keep all data as internal state. Because it's an infinite scroll, not pagination. For example, user scroll down to page 5. And user wants to delete item of page 1. |
Beta Was this translation helpful? Give feedback.
-
|
@taejs At any point in time, that component will have the current, last and next page loaded with a very long array that is otherwise filled with |
Beta Was this translation helpful? Give feedback.
-
|
I see. However, there's another question. React avoid DOM changing using HTML API and prefer to render by state(data). That concept can be done with React? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, with libraries like https://github.com/tannerlinsley/react-virtual or https://github.com/bvaughn/react-window - you should definitely be using one of those when implementing infinite scroll. |
Beta Was this translation helpful? Give feedback.
-
|
alternative lists |
Beta Was this translation helpful? Give feedback.
-
|
What if you want to automatically load all the available pages without user interaction? Example: we have an endpoint that uses pagination, however for 90% of our users pagination is not required. Only our "super users" would need to be able to access all the items. The UI we are using expects to have all the items the user needs available when the component loads. Any ideas? |
Beta Was this translation helpful? Give feedback.
-
|
I will add that I found https://redux-toolkit.js.org/rtk-query/usage/prefetching#prefetching-all-known-pages however this assumes I know the total number from the first call. In my scenario I get a |
Beta Was this translation helpful? Give feedback.
-
|
After stumbling across https://redux-toolkit.js.org/rtk-query/usage/customizing-queries#performing-multiple-requests-with-a-single-query I was able to come up with a solution. If anyone has suggestions around improving this or other ways to achieve this I would be happy to receive them. |
Beta Was this translation helpful? Give feedback.
-
|
If I understood this correctly, it basically fetches all of the pages right away? Doesn't that defeat the purpose of paginating the results? |
Beta Was this translation helpful? Give feedback.
-
MotivationI want to implement one way (top to down) infinite scroll behaviour using RTK Query. ProblemIf I want to refetch all aggregated data on tab focus I will get only last page query. NeedI need a way to change query cache key and originalArgs in the Somewhere in my component: const { data, error, isFetching, isLoading, refetch } =
useGetAllPostsQuery({
limit,
page,
})
// Initiate infinite scrolling behaviour.
const infiniteScrollObserverTarget = useRef<HTMLDivElement | null>(null)
const entry = useIntersectionObserver(infiniteScrollObserverTarget, {})
const targetIsIntersecting = !!entry?.isIntersecting
// Create new query values when we observer target is intersecting.
useEffect(() => {
if (targetIsIntersecting && !isFetching) {
setPage((currentPage) => currentPage + 1)
}
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [targetIsIntersecting, limit, setPage])And here it is my endpoint definition: endpoints: (builder) => ({
getAllPosts: builder.query<
TGetAllPostsResponse,
TGetAllPostsOptions | void
>({
query: ({
limit = 5,
page = 0,
orderBy = "createdAt",
orderWay = "desc",
} = {}) => {
let queryString = "?"
queryString += `limit=${limit}&`
queryString += `page=${page}&`
queryString += `orderBy=${orderBy}&`
queryString += `orderWay=${orderWay}`
return `posts${queryString}`
},
providesTags: (result) =>
result
? [
...result.data.map(({ id }) => ({
type: "Posts" as const,
id,
})),
]
: [{ type: "Posts", id: "LIST" }],
async onCacheEntryAdded(
arg,
{ cacheDataLoaded, getState, updateCachedData }
) {
// Check if we just not started to build the infinite list.
// You must reset the page after sort order change etc.
if (arg?.page && arg?.limit && arg?.page > 1) {
// wait for the initial query to resolve before proceeding
await cacheDataLoaded
// get key of the last query, the query before the current one
// "getAllPosts({"limit":5,"page":1})"
const lastQueryKeyParams = JSON.stringify({
...arg,
page: arg.page - 1,
})
const lastQueryKey = `getAllPosts(${lastQueryKeyParams})`
const lastCacheEntry = (
getState().api.queries[lastQueryKey]
?.data as TGetAllPostsResponse
).data
// add previous data to the current one
updateCachedData((draft) => {
draft.data.unshift(...(lastCacheEntry as TPostsItem[]))
})
}
},
}),
}),I think that my custom types are irrelevant here in this thread. |
Beta Was this translation helpful? Give feedback.
-
|
You can override cache key generation as a createApi option, but the args will not override there. Why does this approach not work for you? It should fulfill your requirements. |
Beta Was this translation helpful? Give feedback.
-
|
I will investigate that approach. I have not saw it before I implemented mine. |
Beta Was this translation helpful? Give feedback.
-
|
Could you provide fully working example? I'm a bit confused about these empty array positions. |
Beta Was this translation helpful? Give feedback.
-
|
No, I don't really have a use case for something like that at the moment. You would want to keep the empty array positions as when using a virtualization library like So, you would have So your virtualization library might be accessing |
Beta Was this translation helpful? Give feedback.
-
|
Good example, though note Import the inbuilt serializer: import {
defaultSerializeQueryArgs as serializeQueryArgs
} from '@reduxjs/toolkit/query/react';And use like so: const lastQueryKey = serializeQueryArgs({
endpointName: api.endpoint,
queryArgs: arg,
}); |
Beta Was this translation helpful? Give feedback.
-
|
@michalstrzelecki I was able to implement one-way infinite scroll behaviour using RTK Query using a custom Hook. You can check this code file: useInfiniteScroll.ts import { UseQuery, } from '@reduxjs/toolkit/dist/query/react/buildHooks';
import React, { useState, useEffect, useCallback, useMemo } from 'react';
const calculateMaxPages = (total: number, size: number) => {
return Math.ceil(total / size);
};
export const isValidNotEmptyArray = (array: any[]): boolean => {
return !!(array && array?.length && array?.length > 0)
};
export interface IListQueryResponse {
items: any[];
total: number;
page: number;
size: number;
}
const useInfiniteScroll = (useGetDataListQuery: UseQuery<any>, { size = 10, ...queryParameters }) => {
const [localPage, setLocalPage] = useState(1);
const [combinedData, setCombinedData] = useState([]);
const queryResponse = useGetDataListQuery({
page: localPage,
size,
...queryParameters
});
const {
items: fetchData = [],
page: remotePage = 1,
total: remoteTotal = 0,
size: remoteSize = 10
} = queryResponse?.data as IListQueryResponse || {}
useEffect(() => {
if (isValidNotEmptyArray(fetchData)) {
if (localPage === 1) setCombinedData(fetchData);
else if (localPage === remotePage) {
setCombinedData((previousData) => [...previousData, ...fetchData])
}
}
}, [fetchData])
const maxPages = useMemo<number>(() => {
return calculateMaxPages(remoteTotal, remoteSize);
}, [remoteTotal, remoteSize]);
const refresh = useCallback(() => {
setLocalPage(1);
}, []);
const readMore = () => {
if (localPage < maxPages && localPage === remotePage) {
setLocalPage((page) => page + 1);
}
};
return { combinedData, localPage, readMore, refresh, isLoading: queryResponse?.isLoading, isFetching: queryResponse?.isFetching };
};
export default useInfiniteScroll;You can use it on your page in this way. You should use your own custom RTK query service and add its own parameters. I worked perfectly on my react native app. No array repetition and works well when requests last too much time on poor internet connections. const { combinedData, readMore, refresh } = useInfiniteScroll(
useGetProvidersListQuery,
{
latitude: -0.78,
longitude: -78.4,
categoryId: 9
}
); |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jonra1993, |
Beta Was this translation helpful? Give feedback.
-
@jonra1993 How to correctly use it, can you provide the whole example, because i have empty array each time without any data |
Beta Was this translation helpful? Give feedback.
-
|
@jonra1993 Hey, thanks for answer it's realy helpful! upd: |
Beta Was this translation helpful? Give feedback.
-
|
Hi.any updates in 2022. I need a best solution for infinity scroll include cache and optimistic updates. Any one know about this Please give me example. RTK Query is best solution all are things except infinity scroll. Pls help. |
Beta Was this translation helpful? Give feedback.
-
|
@hamzamongam I still stand by my original comment: usually you don't want to merge responses from x different requests together, but just have a few |
Beta Was this translation helpful? Give feedback.
-
|
Any ideas on data queris with cursors (without stable page and offset parameters)? The one with creating page components is pretty nice but it makes impossible correctly restoring scroll position (get index of specific element and scroll to it when necessary in react window or tanstack virtual). |
Beta Was this translation helpful? Give feedback.
-
|
Incase anyone is here and wondering how they can implement and Infinite Scroll in With Redux Tookit Query and React Native Flatlist. Since the release of v1.9+ there's a better recommended way of handling infinite scrolling. Skip to the reply #1163 (reply in thread) /// In postsApi.ts
import { createApi } from "@reduxjs/toolkit/query/react";
import { createEntityAdapter } from "@reduxjs/toolkit";
// Create Adapter For Posts To Avoid Duplicates
const postsAdapter = createEntityAdapter({
selectId: (post) => post.id,
sortComparer: (a, b) => b.createdAt - a.createdAt,
});
const postsApi = createApi({
reducerPath: "posts",
endpoints: (build) => ({
fetchPosts: build.query({
keepUnusedDataFor: 600 // Keep unused for longer,
query: (page) => {
return `posts?page=${page}`;
},
transformResponse: (response) => {
// Return Post To State Using Adapters
return postsAdapter.addMany(
postsAdapter.getInitialState({
hasMorePages: response.hasMorePages,
}),
response.data
);
},
async onQueryStarted(page, { queryFulfilled, dispatch }) {
const { data } = await queryFulfilled;
if (data) {
// Merge App Post Into First Page Using Posts Adapter
dispatch(
postsApi.util.updateQueryData(
"fetchPosts",
1,
(draft) => {
postsAdapter.addMany(
draft,
postsSelector.selectAll(data)
);
draft.hasMorePages;
}
)
);
if (page > 1) {
// Remove Cached Data From State If Not Page 1 Since We Already Added It To Page 1
dispatch(
postsApi.util.updateQueryData(
"fetchPosts",
page,
(draft) => {
draft = postsAdapter.getInitialState();
}
)
);
}
}
},
}),
}),
});
export const {
postsApi
} = postsApi;
export default postsApi;
const postsSelectors = postsAdapter.getSelectors((state) => state);
export { postsSelectors, postsAdapter };On the page you want to render the posts, you can scroll infinitely with an example like this /// PostScreen.ts
import { View, FlatList } from "react-native";
import React, { useEffect, useRef } from "react";
import postsApi, {
postsAdapters,
postsSelectors,
useLazyFetchPostsQuery
} from "../../state/apis/postsApi";
export default function PostsScreen() {
const currentPage = useRef(1);
const [fetchPosts, { isFetching }] =
useLazyFetchPostsQuery();
// Listen For Posts Updates Page 1
const { posts, hasMorePages } =
postsApi.endpoints.fetchPosts.useQueryState(1, {
selectFromResult: (result) => {
return {
hasMorePages: result.data?.hasMorePages,
posts: postsSelectors.selectAll(
result.data ?? postsAdapters.getInitialState()
),
};
},
});
const fetchFirstPage = async () => {
await fetchPosts(currentPage.current);
};
const fetchMorePosts = async () => {
if(!hasMorePages || isFetching) return;
currentPage.current += 1;
await fetchPosts(currentPage.current);
};
useEffect(() => {
// Fetch First Page On Init
fetchFirstPage()
}, [])
return (
<FlatList
data={posts}
renderItem={....}
onEndReached={fetchMorePosts}
/>
);
}For more clarity, I have created an expo snack https://snack.expo.dev/@benqoder/react-native-infinite-scroll-with-rtk-query |
Beta Was this translation helpful? Give feedback.
-
|
@BenQoder thanks for your kindly help. It seems your solution is matched my required feature. thanks again. Merry Xmas. |
Beta Was this translation helpful? Give feedback.
-
|
@BenQoder If you only update the local cache when an item is updated or deleted, your queried data is probably going to be incorrect. i.e. With a page size of 10, you delete an item from page 1, then scroll to trigger You're likely to have similar issues with item updates if it affects the sorted order. |
Beta Was this translation helpful? Give feedback.
-
|
I understand what you are describing but it has not been an issue in my case.
Nevertheless, my suggestion is not final, you can make improvements on it. |
Beta Was this translation helpful? Give feedback.
-
|
@BenQoder Neither of your points address the issue I am describing.
For each of these cases, CRUD causes bugs when you proceed to fetch and merge more data afterwards. #1163 (comment) is the solution I implemented. It's a tradeoff because it doesn't have this CRUD problem, but it makes features like search and list empty rendering difficult. React Query uses a sequential re-fetching strategy to solve these problems. |
Beta Was this translation helpful? Give feedback.
-
|
@markerikson |
Beta Was this translation helpful? Give feedback.
-
|
In your line "posts: postsSelectors.selectAll( where does "postsSelectors" come from ? It does give me a error. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I exported postSelectors from the postApi.ts then I imported it into the Post list screen. |
Beta Was this translation helpful? Give feedback.
-
|
@BenQoder Thanks for you answer and follow up. The api i'm using does not has hasMore pages data. I made some modifications i'm using page attribute. The query works fine. But it does not adds the posts it just replace it. I know i'll have to change to have to merge the actual data with the incoming data. What I do not know is in transformResponse and how this functions should return. |
Beta Was this translation helpful? Give feedback.
-
|
You can find an example on this expo snack https://snack.expo.dev/@benqoder/react-native-infinite-scroll-with-rtk-query |
Beta Was this translation helpful? Give feedback.
-
|
Please implement this feature, really important! |
Beta Was this translation helpful? Give feedback.
-
|
Your solution is good, but only when there is no data manipulation (delete, move, change). It would be cool to see something like react-query https://react-query-v3.tanstack.com/guides/infinite-queries . There is a solution with re-requesting the necessary pages (if I deleted an element, then the current and next pages should be refetched) |
Beta Was this translation helpful? Give feedback.
-
|
As I said: both my solutions will update if data is re-requested after a delete, move or change. I do not know why you assume that would not be the case. |
Beta Was this translation helpful? Give feedback.
-
|
@phryneas Can you show you solutions again, pleaseee) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Just because we had this come up in chat recently and it is not mentioned here - a very viable solution is also something like function InfiniteScroll() {
const [pageCount, setPageCount] = useState(0)
const pages = [];
for (let page=0; i<pageCount; i++) {
pages.push(<Page page={page} key={page} />)
}
return <>
{pages}
<button onClick={() => setPageCount(c => c+1)}>more</button>
</>
}
function Page(props){
const result = usePageData({page: props.page})
return <>...something...</>
}This can easily be combined with something like https://github.com/bvaughn/react-window to have pages out of the visible screen slowly be removed from cache. |
Beta Was this translation helpful? Give feedback.
-
|
That looks like a clean solution, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Either you have the |
Beta Was this translation helpful? Give feedback.
-
|
It seems to be not possible to restore scrolling position if using with libraries like tanstack virtual or react window and having dynamically sized objects |
Beta Was this translation helpful? Give feedback.
-
|
I am using DynamoDB as the data source, and it returns a
ImplementationThe ideal is to use the very first query as a base collection to accumulate and cache the fetched items: import { SerializedError } from '@reduxjs/toolkit';
import { FetchBaseQueryError } from '@reduxjs/toolkit/dist/query';
import { useAppDispatch } from '@src/redux';
// assume we already have a 'readNoteList' endpoint in noteApi,
// thus we have:
import {
noteApi,
useReadNoteListQuery,
useLazyReadNoteListQuery,
} from '@services/modules/notes';
type Note = { id: string; foo: string; bar: number };
type QueryError = FetchBaseQueryError | SerializedError | undefined;
export interface NoteListParams {
limit?: number;
next?: string;
}
export interface NoteListBody {
notes: Note[];
next?: string; // in my case, it's a LastEvaluatedKey returned from DynamoDB
}
export interface UseInfiniteQueryResult {
// data: { notes: [], next: the latest cursor },
// where data.notes is used to collect and cache the 1st and next fetched notes,
// the field `next` is updated to follow the latest cursor returned from backend (e.g. DynamoDB in my case).
data: NoteListBody;
// for the very first fetching
error?: QueryError;
isError: boolean;
isLoading: boolean;
// for the first fetching and next fetching
isFetching: boolean;
// for next fetches
errorNext: QueryError;
isErrorNext: boolean;
isFetchingNext: boolean;
hasNext: boolean;
fetchNext: () => Promise<void>;
refetch: () => Promise<void>;
}
export function useInfiniteReadNoteListQuery(
params: NoteListParams,
fetchAll: boolean = false // if `true`: auto do next fetches to get all notes at once
) {
const dispatch = useAppDispatch();
// baseResult is for example GET from https://exmaple.com/johndoe/notes
const baseResult = useReadNoteListQuery(params);
// nextResults are for example GET from https://exmaple.com/johndoe/notes?next=latest-cursor-value
// trigger may be fired many times
const [trigger, nextResult] = useLazyReadNoteListQuery();
const isBaseReady = useRef(false);
const isNextDone = useRef(true);
// next: starts with a null, fetching ended with an undefined cursor
const next = useRef<null | string | undefined>(null);
// Base result
useEffect(() => {
next.current = baseResult.data?.next;
if (baseResult.data) {
isBaseReady.current = true;
fetchAll && fetchNext();
}
}, [baseResult]);
// When there comes a next fetched result
useEffect(() => {
if (!nextResult.isSuccess) return;
if (
isBaseReady.current &&
nextResult.data &&
nextResult.data.next !== next.current
) {
next.current = nextResult.data.next; // undefined if no data further
// Put next fetched notes into the first queried collection (as a base collection)
// This can help us do optimistic/pessimistic updates against the base collection
const newItems = nextResult.data.data;
const baseCollection = dispatch(
noteApi.util.updateQueryData(
'readNoteList',
params,
(drafts) => {
drafts.next = nextResult.data.next;
if (newItems && newItems.length > 0) {
// depends on the use case,
// maybe we can do deduplication, removal of some old entries here, if required
// ...
// adding new notes to the cache
drafts.data.push(...newItems);
}
}
)
);
}
}, [nextResult]);
const fetchNext = async () => {
if (
!isBaseReady.current ||
!isNextDone.current ||
next.current === undefined ||
next.current === null
)
return;
try {
isNextDone.current = false;
await trigger({
...params,
next: next.current,
});
} catch (e) {
} finally {
isNextDone.current = true;
fetchAll && fetchNext();
}
};
const refetch = async () => {
isBaseReady.current = false;
next.current = null; // restart
await baseResult.refetch(); // resatrt with a whole new refetching
};
return {
data: baseResult.data,
error: baseResult.error,
isError: baseResult.isError,
isLoading: baseResult.isLoading,
isFetching: baseResult.isFetching || nextResult.isFetching,
errorNext: nextResult.error,
isErrorNext: nextResult.isError,
isFetchingNext: nextResult.isFetching,
hasNext: baseResult.data?.next !== undefined,
fetchNext,
refetch,
};
}Usageexport const FooComponent = (props) => {
// ...
const {
data: NoteListBody, // the base collection that accumulates our notes
error,
isError,
isLoading,
isFetching,
errorNext,
isErrorNext,
isFetchingNext,
hasNext,
fetchNext,
refetch,
} = useInfiniteReadNoteListQuery({
// next: undefined,
// (1) next === undefined: base collection is queried from the beginning of the data source;
// (2) next === 'base_collection_start_from_this_cursor': base collection is queried
// from some point of the data source.
// In most cases, choose (1), leave next undefined.
},
// true // set 2nd arg to true will fetch all notes at once when the first query fired
);
// ...
const onEndReachedFetchNext = () => {
if (hasNext && !isFetching) {
fetchNext();
}
};
return (
<View>
...
<FlatList
data={NoteListBody.data} // the base collection that accumulates our notes
initialNumToRender={10}
scrollEventThrottle={16}
refreshing={refreshing}
onRefresh={() => refetch()}
keyExtractor={keyExtractor}
renderItem={renderSiteItem}
...
onEndReachedThreshold={0.01}
onEndReached={onEndReachedFetchNext}
/>
</View>
);
};(Optional) Make a helper functionWe can make a helper function to encapsulate the logics: export function createUseInfiniteQuery<TResult, TParams>(api: any, endpointName: string) {
return function (
params: TParams,
fetchAll: boolean = false
) {
// Sorry for not providing the details, I'm still strugging with the typing things.
// There are many `any` types, it's ugly.
}
};I use the helper function in my // ...
export const {
useCreateNoteMutation,
useReadNoteQuery,
useUpdateNoteMutation,
useDeleteNoteMutation,
useReadNoteListQuery,
useLazyReadNoteListQuery,
} = noteApi;
export const useInfiniteReadNoteListQuery = createUseInfiniteQuery<
ReadNoteListBody,
ReadNoteListParams
>(noteApi, 'readNoteList');Thanks @davidtkramer and @phryneas for your solutions that inspire me a lot! |
Beta Was this translation helpful? Give feedback.
-
|
@8bithero Have you tried the approach |
Beta Was this translation helpful? Give feedback.
-
|
@simenkid Does it work with invalidatetags? |
Beta Was this translation helpful? Give feedback.
-
|
@CursedMun It should be working with invalidateTags. The implementation has nothing to do with the RTKQ invalidation itself. Maybe you can check if your |
Beta Was this translation helpful? Give feedback.
-
|
@simenkid they truly match, it will work with the first page because params on the fetch would be the initial ones, but if you update some element in the 2nd or further page it won't update the elements in that range |
Beta Was this translation helpful? Give feedback.
-
|
@CursedMun Sorry, it's my bad. You're correct. Since the futher fetches were fired with lazy queries (triggers), the further data won't be tagged and cached. In my case, most of the time, I choose to patch the items in the cache (accumulated in the very first query), e.g. |
Beta Was this translation helpful? Give feedback.
-
|
To do this we simply need access to the state in transformResponse!. Guys untie our hands please. |
Beta Was this translation helpful? Give feedback.
-
|
To be honest I am a bit ashamed, that I wrote my comment under frustration and disappointment that the newest version of one of my favorite libraries is not perfect. |
Beta Was this translation helpful? Give feedback.
-
|
I want to add to this subthread: While this can be done in That's why I really do encourage to handle these as independent cache entries and have your component subscribe to only those parts of it that it really needs - usually everything in view, a bit to the top and a bit to the bottom, but not much more. That way, anything out of "scroll sight" will be removed from the cache if you didn't use it for a while. It can always just be re-requested from the server in the very unlikely case that a user scrolls upwards more than two pages more than 60 seconds later. |
Beta Was this translation helpful? Give feedback.
-
|
@phryneas you are absolutely right. Thank you for sharing much better approach. I will try it and share my solution. |
Beta Was this translation helpful? Give feedback.
-
|
Ideally by calling |
Beta Was this translation helpful? Give feedback.
-
|
Might be cool to have a clean way to optimistically update groups of caches. For example, if you have intersecting two pages of cache in a viewport Update: |
Beta Was this translation helpful? Give feedback.
-
|
After examining all the examples and what has been done, I found a method and applied it. I created a state and if the query isFetching false, I found a solution to throw the values in the request into the state. If refreshControl happens in flat list on React native side, I reset my state. Also, there is no problem as I request again with rtk query. In the State, I keep the id key as {id1: {dataObject}} if the value is my value, so if the request is made again in the possible rtk query, the final state will be recorded on it. I wanted to share the solution with you. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
@gentlee : I removed that comment, because it didn't seem relevant to the topic at hand. And frankly, your attitude through this whole thread has not been helpful or respectful. It's one thing to say "I have another way to do X". It's another thing to jump into a thread and label the tool being discussed as "garbage". Please stop. |
Beta Was this translation helpful? Give feedback.
-
|
Although @gentlee put it harshly, which I condemn, I would like to echo his point: in the last 6 years of development in React-Native, I do not remember 1 case when I would need to implement pagination-based infinite scrolling in any other way. It is always the same, because there are FlatList, ScrollView components (or their analogues from additional libraries) and they all work the same. I also have experience in the web, and a web project right now on which I have implemented a similar scrolling - I understand your arguments about the different needs of different people and agree with them! But I was lucky that the project was small; in a large project this could be a really complicated routine. Considering the whole direction has a unified approach, it seems like a cool solution would be to have an additional part of the package that is cut off for those who do not use it, such as in lodash. Or at least a full-fledged working example in the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
@JerakRus I'm... not quite sure what you're suggesting there, particularly the last paragraph. As a general status update: after having spent all of last year working on the RTK 2.0 major package updates, and the first half of this year revamping the "Redux Essentials" tutorial, I finally have time to turn my attention to working on RTK Query feature requests. Shipping official infinite query support for RTK Query is now my current priority (although as always that's "with the amount of time I can actually put into working on Redux maintenance efforts"). I did some initial research into how various data fetching libs implement their infinite query support, primarily looking at React Query but also libs like SWR. We've got a user-contributed draft PR over in #4393 that is attempting to implement an equivalent of React Query's public API on top of RTKQ's internals. I rebased that so it compiles. The original author said he'd have time to start looking at that again, and I'm trying to find time to understand how it works so we can try it out further and see what's needed. Lenz and I are also supposed to have a chat with Dominik from React Query in a couple weeks. So, we're finally working on this, after having worked through other higher priority tasks. I don't have any ETA for when we'll ship this official infinite query support, but this is the major priority atm. I'm not sure if that specifically answers your question, since I'm not clear on what you're asking for exactly, but that's where things stand at this point. |
Beta Was this translation helpful? Give feedback.
-
|
@JerakRus I even implemented my own lib RRC, much simpler, with normalization and infinite pagination out of the box. Give it a try. |
Beta Was this translation helpful? Give feedback.
-
|
@markerikson @gentlee |
Beta Was this translation helpful? Give feedback.
-
|
I have created a hook called useInfiniteQuery, which has an API similar to React Query. It is working on my project. I hope that in the following days I will have some time to create a repo. |
Beta Was this translation helpful? Give feedback.
-
|
How can I use this hook in a component? |
Beta Was this translation helpful? Give feedback.
-
|
Can you Help with the types please? |
Beta Was this translation helpful? Give feedback.
-
if RTK-query supports global cache client such as react-query 's QueryClient instance, we can fix this issue. |
Beta Was this translation helpful? Give feedback.
-
|
it doesn;t support previous page cache key, |
Beta Was this translation helpful? Give feedback.
-
|
@panda919 : I don't know what you mean by that. Can you give an example? You can use those utilities to set or update any cache entry if you have the right cache key argument. |
Beta Was this translation helpful? Give feedback.
-
|
2939 |
Beta Was this translation helpful? Give feedback.
-
|
I'm afraid there's a bit of a language barrier, unfortunately, and I don't understand what you're trying to do exactly. Can you post actual example code that shows what you want to do? |
Beta Was this translation helpful? Give feedback.
-
|
maybe its explain helps you . |
Beta Was this translation helpful? Give feedback.
-
|
Hi Team, I have recently started using RTK Query in my RN project. I am currently having a problem to invalidate the cached data after mutation. Below is my problem. I am maintaining page state in my component and incrementing it after onEndReached event fires. I have a notification data fetched from the server. All unread notifications can be marked as Read (individually by tapping on each item). Problem - If the user scrolls to the second page, page state is incremented by 1. Now if the user scrolls up to page 1 and tries to mark the message as read (Mutation), refetching request is done for page 2. Please need your help on this problem. Currently the backend only supports getting all notifications, hence invalidating by individual ID is not possible. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @kiranNegiloni ! I have some questions on some parts of your msg above 👆. You said:
My question is :
Next, you said:
My question is:
Next, you said:
I'd say: Example: export const notificationSlice = createSlice({
name: "notification",
initialState,
reducers: {...},
extraReducers: (builder) => {
builder.addMatcher(
api.getNotifications.matchFulfilled, (state, { payload }) => {
// test on a variable if you should concatenate elements or get full list
if(state.shallConcat)
state.list.concat(payload.list);
else
state.list = payload.list;
}
)
}
});even if you're using queryFn or transformResponse(), you can simply put something liek this to solve your issue. Otherwise, I'd suggest you to share a minimal example on Github or Expo Snack, in order to know exactly what is your problem. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @firas1220, Thanks Alot for the detailed response. Yes, We are using React Native Flatlist. By maintaining a separate slice for notifications, Should i stop invalidating the cache and directly dispatch an action to update this reducer state? Will it update the cache automatically? I will try to share the minimal example. Thanks Again. |
Beta Was this translation helpful? Give feedback.
-
|
Hiya! By using a separate a slice you can control the list of notifications (concatenate lists or get new one) BUT you have to be aware of something important: if, for example, you're on page 1, you tap a notification to mark it "READ" then you go to page 2 and 3, at this time you have to say to RTK query: " Bring me elements in range from page 1 to 3 from API again"! which means, you have to pass some arg like Also, when you call the function App() {
const { pageRange} = useRootSelector(notificationSelector);
const [ readNotification ] = useReadMutation();
const { refetch: refetchNotifications } = useGetNotificationsQuery({ pageRange }, { refetchOnMountOrArgChange: true });
const handleReadNotification = useCallback( (args) => {
// read a specific notification!
readNotification(args);
// refetch all notifications
refetchNotifications();
}, []);
return (...)
}FWIW hope it helps |
Beta Was this translation helpful? Give feedback.
-
|
@kiranNegiloni Hey, I've come across a similar problem and here's how I solved it: First, I realized that only pushing new items wouldn't be enough because after invalidating the query cache, I always would fetch with the cached args, but there are going to be occasions where I would need a different behavior, here them:
The solution that I've found was adding a custom logic for each case listed above and updating the current cache in the BUT FIRST, you need to change the query args to make the code above work, so whenever you run a mutation, you'll need to trigger the query again, passing the page you want to refetch as an argument.
Let me know if you have any questions! |
Beta Was this translation helpful? Give feedback.
-
|
@enrickdaltro Thanks Alot for the detailed answer. I will apply this solution and provide feedback. |
Beta Was this translation helpful? Give feedback.
-
|
any plan on supporting this feature out of the box in the next major version? |
Beta Was this translation helpful? Give feedback.
-
|
@bryantobing12 Hi. Saw you raise concerns about infinite queries and RTKQ on Twitter ( https://twitter.com/bryanltobing/status/1625113439550189568 ). There's a few different issues involved here. The first is that as mentioned earlier in the thread, Lenz is our resident expert on RTKQ and data fetching stuff, and he feels that there's just too many possible scenarios and approaches for potentially implementing infinite queries, and that if we ship something specific it would lock out the other use cases:
Second issue is that RTK is maintained by really just the two of us, and we do this in our spare time. I've been trying to do some prep work for RTK 2.0 over the last few weeks, including modernizing the package publishing and build tooling, and working on merging long-overdue TS updates to the Third is that there's many other requests for features, changes, and fixes. There's a couple dozen open issues regarding the RTKQ codegen packages. Some users want us to add built-in functionality for code splitting and dynamic loading of Redux functionality. Meanwhile, there's also open questions around React Suspense and server-side rendering, and how the various data fetching libraries (React Query, Apollo, SWR, Urql, RTK Query) are supposed to fit into that world. (In fact, the maintainers of these libs actually have a meeting scheduled with the React team this week to try to figure out how any of that is supposed to work.) And oh, yeah, we're also sorta vaguely trying to have actual lives, too :) I think it's clear from this thread that there is a real desire to have some kind of built-in support around infinite queries in RTKQ, and given that it is something I would like us to try to cover at some point. (Just asked for some more examples of use cases and API design on Twitter: https://twitter.com/acemarke/status/1625525439228784640 ) But, given all the other concerns we're juggling right now, it just isn't something we have time to prioritize or focus on atm. I am curious: what specific infinite-query-related use cases does your app need to handle? What does your current implementation look like? I saw you expressing concerns about having to do workarounds for managing state yourself - can you give specific examples? At a minimum, it might be nice if we could comb through this page and list some of the specific recipes discussed here in our docs. But again, that requires time and effort and prioritization, and we're very limited on that front. It would be very helpful if folks from the community could pitch in with that. We welcome all attempts at useful contributions, and we'd love to have folks help improve our docs or contribute better functionality! |
Beta Was this translation helpful? Give feedback.
-
|
Folks, I've gone ahead and created a separate discussion thread in #3174 to get feedback on the different potential use cases people have for doing "infinite query"-type behavior (as shown in Lenz's comment about "pagination vs cursor vs offset" and "full list vs individual fetching"). We'd appreciate if you could submit of use cases in that thread so we can have an idea of the different approaches people need to deal with! |
Beta Was this translation helpful? Give feedback.
-
|
For anyone who wants to implement infinite query with single cache entry or cursor based pagination, check out my solution and see if it can help you. Prerequisites
interface PaginationArg {
pageSize: number;
cursor: string | null;
}
interface PaginationData<T> {
items: T[];
cursor: string | null;
}
ImplementationTo combine subsequent data in a single cache entry, we can use endpoints: (builder) => ({
getItems: builder.query<PaginationData<Item>, PaginationArg>({
query: (arg) => ({ url: 'items', params: arg }),
merge: (currentData, { items, cursor }) => {
currentData.items.push(...items);
currentData.cursor = cursor;
},
serializeQueryArgs: ({ endpointName }) => {
return endpointName;
},
forceRefetch: ({ currentArg, previousArg }) => {
return !!currentArg?.cursor && currentArg !== previousArg;
},
providesTags: ...
}),
})But the problem with this approach is when we try to refetch (either by manually or cache invalidation), it doesn't work properly since refetch runs with I fixed this behavior by creating a custom redux middleware which intercepts and modifies actions dispatched by api endpoints. When the query runs, the api dispatches import { Middleware, isPending } from '@reduxjs/toolkit';
import type { AppState } from './store';
export const customMiddleware: Middleware = (api) => (next) => (action) => {
// Exclude unrelated actions
if (!isPending(action) || !action.meta || !action.meta.arg) {
return next(action);
}
const { type, endpointName, originalArgs } = action.meta.arg;
const state = api.getState() as AppState;
const latestQuery = state.api.queries[endpointName];
// Exclude unrelated actions
if (type !== 'query' || !originalArgs || !latestQuery) {
return next(action);
}
const queryArg = originalArgs as PaginationArg;
const latestData = latestQuery.data as PaginationData<any>;
const { items: latestItems, cursor: latestCursor } = latestData;
// Exclude first query runs
if (!latestItems || !latestItems.length || latestCursor === undefined) {
return next(action);
}
// Exclude normal subsequent queries
if (queryArg.cursor === latestCursor && latestCursor !== null) {
return next(action);
}
// Modify originalArgs
action.meta.arg.originalArgs = {
...originalArgs,
pageSize: latestItems.length,
cursor: null,
refetch: true,
} as PaginationArg;
return next(action);
};This middleware will only modify the action if:
Then we can distinguish the
To make refetch performs as we want, modify Then update merge: (currentData, { items, cursor }, { arg }) => {
if (arg.refetch) {
currentData.items = items;
} else {
currentData.items.push(...items);
}
currentData.cursor = cursor;
},If your using typescript, you also need to update interface PaginationArg {
pageSize: number;
cursor: string | null;
refetch?: boolean;
}I've tested this approach in my app and it seems working properly. And I think you can also apply this to offset based pagination by comparing current page numbers instead of cursors. |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to comment this totally solved my cache invalidation issue since we're also using cursor based pagination. Thanks a ton. |
Beta Was this translation helpful? Give feedback.
-
|
@markerikson @phryneas Hello guys. export const postApi = rtkQuery.injectEndpoints({
getPostsByUserId: builder.query<GetPostsByUserIdResponse, GetPostsByUserIdRequest>({
query: ({ id, ...params }) => ({
url: `post/user/${id}?${transformObjToUrlParams(params)}`,
}),
serializeQueryArgs: ({ endpointName }) => endpointName,
forceRefetch: ({ currentArg, previousArg }) => currentArg !== previousArg,
merge: (currentCache, newCache, { arg: { offset, resetCache, deleteItem } }) => {
const currentPage = (currentCache.data.length - POSTS_LIMIT) / POSTS_LIMIT;
const nextPage = offset / POSTS_LIMIT;
if (resetCache) {
currentCache.data = newCache.data;
} else if (deleteItem) {
currentCache.data = currentCache.data.filter(item => item.id !== deleteItem);
} else if ((currentPage > 0 && nextPage === currentPage) || nextPage < currentPage) {
currentCache.data.splice(offset, newCache.data.length, ...newCache.data);
} else {
currentCache.data.push(...newCache.data);
}
currentCache.limit = newCache.limit;
currentCache.offset = newCache.offset;
currentCache.count = newCache.count;
},
keepUnusedDataFor: infinity,
}),
updatePost: builder.mutation<UpdatePostResponse, UpdatePostRequest>({
queryFn: (...propsQuery) =>
infiniteUpdaterBaseFn<UpdatePostResponse, typeof propsQuery[0]>({
propsQuery,
options: {
url: `post/${propsQuery[0].id}`,
method: 'PATCH',
rtk: () => postApi,
endpointName: 'getPostsByUserId',
},
}),
}),
})
type AxiosBaseQuery = ReturnType<typeof axiosBaseQuery>;
type InfiniteUpdaterBaseFnProps<T> = {
propsQuery: [
T,
BaseQueryApi,
BaseQueryExtraOptions<AxiosBaseQuery>,
(arg: Parameters<AxiosBaseQuery>[0]) => ReturnType<AxiosBaseQuery>,
];
options: {
url: string;
method: string;
rtk: any;
endpointName: string;
};
};
export const infiniteUpdaterBaseFn = async <T extends AnyObject, P extends InfiniteScrollRequest>({
propsQuery: [data, api, , fetchToBQ],
options: { url, method, rtk, endpointName },
}: InfiniteUpdaterBaseFnProps<P>): Promise<QueryReturnValue<T, BaseQueryError<AxiosBaseQuery>>> => {
const res = await fetchToBQ({
url,
method,
data,
});
const rootState = api.getState() as RootState;
const state = rootState['rtkReducer'];
const prevCacheData = state.queries[endpointName]?.data as { data: T['data'] };
const index = prevCacheData?.data?.findIndex((item: { id: number }) => item.id === data.id) || 0;
api.dispatch(
rtk().endpoints[endpointName].initiate(
{
id: data.refetchData?.userId,
limit: 5,
offset: index,
deleteItem: method === 'DELETE' ? data.id : undefined,
},
{
subscribe: false,
forceRefetch: true,
},
),
);
if (res.error) {
return {
error: res.error,
};
}
return {
data: res.data as T,
};
}; |
Beta Was this translation helpful? Give feedback.
-
|
I have changed ininiteUpdaterBaseFn function in .js format but copied rest but i receive undefined from currentCache.data. Really appresiate any help. :) |
Beta Was this translation helpful? Give feedback.
-
|
I need the infinite scroll possibility on react native, the way they handle data rendering is a bit different compared to the web so the solution proposed by @phryneas wouldn't really work. In this regard I have several questions:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello, I hade the same requirement to have an infinite scroll in both direction. After reading all the threads on the topic, it seems to me that the most easiest and reliable solution is not to touch RTK query endpoints and try to build on the top of @phryneas initial proposition, to keep delegating caching and invalidating to RTK. // the useInfiniteScroll can take as a props any useQuery generated by RTK
export function useInfiniteScroll<ApiResponseDto extends ResponseBase>(
useGetQuery: UseGetQueryProps<ApiResponseDto>
) {
// getting the current state from redux store.
// You can pass it as a props if you wish or manage it with a useState
const page = useAppSelector((state) => state.filter.page);
const paginatedQueryParams = useAppSelector((state) => state.filter);
const limit = useAppSelector((state) => state.filter.limit);
const dispatch = useAppDispatch();
// this is the original recommandation from @phryneas.
// It ensures that the api store is fully managing the caching, invalidating...
const lastQueryResponse = useGetQuery({
...paginatedQueryParams,
page: page - 1,
});
const currentQueryResponse = useGetQuery(paginatedQueryParams);
const nextQueryResponse = useGetQuery({
...paginatedQueryParams,
page: page + 1,
});
const combinedData = useMemo(() => {
const arr = new Array(limit * (page + 1));
for (const data of [
lastQueryResponse.data,
currentQueryResponse.data,
nextQueryResponse.data,
]) {
if (data) {
const offset = (data.page - 1) * data.limit;
arr.splice(offset, data.data.length, ...data.data);
}
}
const isNotFullyEmpty = arr.some((value) => value !== undefined);
return isNotFullyEmpty ? arr : [];
}, [
currentQueryResponse.data,
lastQueryResponse.data,
limit,
nextQueryResponse.data,
page,
]);
const { page: remotePage = 1, hasNextPage = false } =
currentQueryResponse?.data || {};
const isFetching = useMemo(
() =>
lastQueryResponse?.isFetching ||
currentQueryResponse?.isFetching ||
nextQueryResponse?.isFetching,
[
currentQueryResponse?.isFetching,
lastQueryResponse?.isFetching,
nextQueryResponse?.isFetching,
]
);
// this part of the code is managing the scroll up and down event.
// make sure you are using an intersection observer and not the scroll event.
// it will save you hours of debuging :)
// this part of the code can be abstracted in a useOnScreen custom hook
const lastIntObserver = useRef<IntersectionObserver | null>(null);
const lastRowRef = useCallback(
(node: HTMLDivElement | null) => {
if (isFetching) return;
if (lastIntObserver.current) lastIntObserver.current.disconnect();
lastIntObserver.current = new IntersectionObserver((entries) => {
if (entries[0].isIntersecting && hasNextPage && page === remotePage) {
dispatch(updateCurrentPage(page + 1));
}
});
if (node) lastIntObserver.current.observe(node);
},
[dispatch, hasNextPage, isFetching, page, remotePage]
);
const firstIntObserver = useRef<IntersectionObserver | null>(null);
const firstRowRef = useCallback(
(node: HTMLDivElement | null) => {
if (isFetching) return;
if (firstIntObserver.current) firstIntObserver.current.disconnect();
firstIntObserver.current = new IntersectionObserver((entries) => {
if (entries[0].isIntersecting && page > 1) {
dispatch(updateCurrentPage(page - 1));
}
});
if (node) firstIntObserver.current.observe(node);
},
[dispatch, isFetching, page]
);
return {
combinedData,
lastRowRef,
firstRowRef,
isFetching,
};
}I hook up firstRowRef to the first row in my table and lastRowRef to the last one. to make everything works together. |
Beta Was this translation helpful? Give feedback.
-
|
If anyone asks how to use this hook :
const {
combinedData: posts,
lastRowRef,
firstRowRef,
isFetching,
} = useInfiniteScroll(useGetAllPostsQuery);
return (
<div>
{posts?.filter(Boolean).map((post, index, arr) => (
<Post
id={post.id}
key={post.id}
ref={index === 0 ? firstRowRef : index === arr.length - 1 ? lastRowRef : null}
post={post}
/>
))}
{isFetching && "Loading more..."}
</div>
); |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I am wondering how can i use useInfiniteScroll hook in react native Flatlist. |
Beta Was this translation helpful? Give feedback.
-
|
Hint how to do with next_page_token ? |
Beta Was this translation helpful? Give feedback.
-
|
Hi. This is my example. I did it with useLazyQuery because I wanted to get rid of waiting for the result. I wanted to get it as soon as I got the result. Also with react-cool-inview, we get rid of the constant scrolling. Hope this helps you :) // useInfiniteScroll.js import { useState, useEffect, useCallback } from 'react';
import { useInView } from 'react-cool-inview'; // https://www.npmjs.com/package/react-cool-inview
import { emptySplitApi } from './emptySplitApi'; // https://redux-toolkit.js.org/rtk-query/usage/code-splitting
const useInfiniteScroll = (endpointName, queryParameters, queryOptions) => {
const [page, setPage] = useState(1);
const [combinedData, setCombinedData] = useState([]);
const [
trigger,
{
data: { data: currentData = [], ...pagination } = {},
isLoading,
isFetching,
},
lastPromiseInfo,
] = emptySplitApi.endpoints[endpointName].useLazyQuery(queryOptions); // https://redux-toolkit.js.org/rtk-query/api/created-api/hooks#uselazyquery
const { observe } = useInView({
threshold: 0.8, // default is 0
// When the last item comes to the viewport
onEnter: ({ unobserve }) => {
// Pause observe when loading data
unobserve();
// Load more data
if (pagination?.next_page_url !== null && !isFetching) {
setPage(page => page + 1);
}
},
}); // https://www.npmjs.com/package/react-cool-inview#infinite-scroll
useEffect(() => {
// Add a subscription
const result = trigger({
page,
limit: 15,
...queryParameters,
})
.unwrap()
.then(data => setCombinedData(previousData => [...previousData, ...(data.data ?? [])]))
.catch(console.error);
// Return the `unsubscribe` callback to be called in the `useEffect` cleanup step
return result.unsubscribe;
// See Option 3. https://github.com/facebook/react/issues/14476#issuecomment-471199055
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [trigger, page, JSON.stringify(queryParameters)]);
const refresh = useCallback(() => {
setPage(1);
}, []);
return {
combinedData,
currentData, // current page data
page,
refresh,
isLoading,
isFetching,
itemRef: observe,
lastArg: lastPromiseInfo.lastArg
};
};
export default useInfiniteScroll;// posts.js import React from 'react';
import useInfiniteScroll from './useInfiniteScroll';
const Posts = () => {
const {
combinedData: posts,
itemRef,
isFetching,
isLoading,
} = useInfiniteScroll('getPosts');
if (isLoading) {
return 'Loading...'
}
return (
<ul>
{posts.map((post, index) => (
<li
key={post.id}
ref={index === posts.length - 1 ? itemRef : null} // If the last item in the viewport, the next page is requested
>
// your code
</li>
))}
</ul>
);
};
export default Posts;
|
Beta Was this translation helpful? Give feedback.
-
|
your hook will duplicate the same data in the combinedData array. For example, if you fetch page 1 with a limit of 15 posts,
useEffect(() => {
// Add a subscription
const result = trigger({
page,
limit: 15,
...queryParameters,
})
.unwrap()
.then((data) => {
setCombinedData((previousData) => {
// Check if data for new page is already in combinedData
const newData = data.filter((item) => !previousData.some((prevItem) => prevItem.id === item.id));
return [...previousData, ...newData];
});
}) //! data shape based on transform responce
.catch(console.error);
// Return the `unsubscribe` callback to be called in the `useEffect` cleanup step
return result.unsubscribe;
// See Option 3. https://github.com/facebook/react/issues/14476#issuecomment-471199055
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [trigger, page, JSON.stringify(queryParameters)]);
|
Beta Was this translation helpful? Give feedback.
-
|
2023 and still not a fancy solution for this. Moving to react-query again! |
Beta Was this translation helpful? Give feedback.
-
|
@jhoanborges : per all of our ongoing updates, our current focus is on trying to get RTK 2.0 out the door. We're doing this in our spare time (and primarily me atm, because the other maintainers have been too busy with personal lives to spend much time on OSS lately). Per #958 (comment) , we're going to look at RTKQ changes after 2.0 ships, and I do want to look at having some kind of infinite query support built in. Rather than complaining, it would help if you could comment over in #3692 and leave detailed examples of potential infinite query use cases and suggestions on what a possible API would look like for you. |
Beta Was this translation helpful? Give feedback.
-
|
@markerikson just curious if there are any plans for supporting the infinite scroll out of the box? |
Beta Was this translation helpful? Give feedback.
-
|
@alex-mironov : there's an open PR from a contributor with a notional first draft of an infinite query API over at #4393 . We haven't had time to take a look and try it out yet, but we'd appreciate feedback on it! |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, I am able to achieve the infinity scroll but it does not work with rtk query tags if a post is deleted or new is added the list should be updated automatically as how tags works. Could anybody provide example how it should work with tags |
Beta Was this translation helpful? Give feedback.
-
see: #1163 (comment) and my reply for how to use it This solution worked for me after trying almost all other solutions, and it also works for tags. |
Beta Was this translation helpful? Give feedback.
-
|
As a general FYI for anyone who's still subscribed to this thread: I've finally had time to seriously focus on figuring out how we're going to add official infinite query support to RTK Query, and we've got some good progress! 🎉 Earlier this year, a user submitted a draft PR that tried to implement an equivalent of React Query's public API on top of RTK Query's internals: That PR had sat there untouched, since neither Lenz nor I had time to look at i. In the last couple weeks I've had both the time and energy to prioritize understanding how infinite queries work in general, how React Query's API is designed and implemented, and how this draft PR is implemented and what it actually does thus far. Over the last few days, I've done some significant work on that draft to fix issues with the TS types, add some tests, clean up some of the rough spots in the API design, and improve the functionality. Also, Lenz and I met with Dominik (React Query maintainer), and discussed how their implementation works and why they made certain design decisions. As of right now, the draft PR in #4393 builds and passes some initial tests. I need to add a lot more tests and try it out in some actual meaningful examples, but I think what's there is actually ready for some brave folks to try it out and give us feedback. You can try installing the PR preview build using the installation instructions from the "CodeSandbox CI" job listed at the bottom of the PR. Please leave comments and feedback over in that PR! My current somewhat ambitious goal is to ship a final version of infinite query support for RTKQ by the end of this year. I am absolutely not going to guarantee that :) It's entirely dependent on how much free time I have to dedicate to this effort, how complicated this turns out to be, and how much polish is needed. But in terms of maintenance effort, shipping this is now my main priority! |
Beta Was this translation helpful? Give feedback.
and others
Status Update, 2024-10-27
We're now actively working on a PR to implement official infinite query support!
Please see that PR for progress updates, and try it out and give us feedback!
Original Answer
Copying my answer from there over here so that people find it more easily 🙂 (also, here would be a generally better place to further discuss any upcoming problems since SO doesn't realle encourage much discussion)
I think most implementations overcomplicate the problem of "infinite scroll" by a lot.
You can achieve this by stepping a bit back and thinking about what you really need:
Since we are lazy a…