-
Hi, first of all — thanks for the amazing work on React Query. So we abstracted that into a small reusable hook that looks like this: export function useIntersectionQuery<...>(...) {
const { isIntersecting, ref } = useIntersectionObserver();
const { data, fetchNextPage, isFetchingNextPage, hasNextPage } = useInfiniteQuery(queryOptions);
useEffect(() => {
if (isIntersecting && hasNextPage && !isFetchingNextPage) {
fetchNextPage();
}
}, [isIntersecting, hasNextPage, isFetchingNextPage, fetchNextPage]);
return { ref, data };
} And then in our component: const { ref, data } = useIntersectionQuery({ ... });
return (
<>
{data.pages.map(...)}
<div ref={ref} />
</>
); 🧠 Why I’m bringing this upIt’s a very common pattern when working with infinite queries, and we noticed:
💡 What I’m suggestingWould it make sense to include something like this in React Query’s core, or at least as an official helper/utility? Something like: const { ref, data, ... } = useInfiniteQueryWithIntersection({
queryKey: ...,
queryFn: ...,
...
}); or useInfiniteQuery({
...,
autoFetchOnIntersect: true,
intersectionTarget: ref,
}); Thanks for reading — I’d love to hear your thoughts on whether this makes sense for the core or not! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Wouldn’t shipping this in query core risk breaking its runtime agnostic contract ? The package is used in React Native, server components, Solid, Vue, Svelte, Angular, etc... So we’d probably need browser-specific code behind conditional imports, no ? That said, if the pattern is clearly widespread maybe adding an official example to the docs could still be a big win ? |
Beta Was this translation helpful? Give feedback.
-
this feature request doesn’t meet the usual criteria to add features to the lib:
|
Beta Was this translation helpful? Give feedback.
this feature request doesn’t meet the usual criteria to add features to the lib:
https://tkdodo.eu/blog/oss-feature-decision-tree