Intersection-based auto-pagination helper

[ayden94]

Hi, first of all — thanks for the amazing work on React Query.
We’ve been building features with useInfiniteQuery, and one small thing we kept repeating was wiring it up to an IntersectionObserver for infinite scroll.

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 up

It’s a very common pattern when working with infinite queries, and we noticed:

• This pattern shows up in many apps and blog posts (all slightly different).
• A helper like this could reduce boilerplate and lower the barrier to using infinite queries well.
• Conceptually it belongs very close to React Query’s useInfiniteQuery itself.

💡 What I’m suggesting

Would 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!

[LeDevNovice]

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 ?

[ayden94]

Thanks for your comment!
I completely understand that including IntersectionObserver logic in React Query’s core could be challenging in terms of maintaining runtime agnosticism. Since React Query runs in a variety of environments, including platforms like React Native and server components, introducing browser-specific APIs or React-centric features into the core could lead to issues. Conditional imports or environment checks would likely be necessary to handle that safely.

Personally, I think it would be great if this kind of feature could be included in the core. However, since I don’t fully understand the internal architecture of React Query, I can't say with confidence that it should be included. That said, I do believe that providing an official example or a separate utility hook in the documentation would be a meaningful and practical alternative.

Given how common and useful this pattern is, it would be great to have a standardized guide that could benefit the community.

[TkDodo]

this feature request doesn’t meet the usual criteria to add features to the lib:

• it’s easily doable in user-land
• there isn’t a simple API we could adopt because there are so many variations of implementing intersection observer.

https://tkdodo.eu/blog/oss-feature-decision-tree