Using useInfiniteQuery() with localStorage persister isn't working as expected

[GarrisonBates]

Hello,

I'm using infinite queries that fetch both ways. For context, it's a messaging feature within my app with a maxPages limit, so I need to be able to paginate both forward and backward. I've set up infinite queries for several other data types so I didn't expect this to be too tricky. But the bidirectional aspect has added a lot more complication than I would've hoped.

The actual infinite scroll works fine. If I delete the localStorage cache, on the first page load it fetches fine. Then when I scroll upwards, it fetches the older messages correctly.

But if I refresh the page, suddenly no messages are fetched. Seems like it may have something to do with the fact that since my "get previous page" intersection observer is triggered on first mount, RQ attempts to fetch previous page, which returns an empty array. So I end up with pages that looks like: [ [], [<actual content>] ]

When the page is refreshed, only one fetch request is sent, and it uses the pageParam from the very latest message, trying to fetch messages newer than the newest message. In other words, it returns empty array, and no messages are fetched.

Does anyone know why this may be happening? Is there a way to use the persister with infinite query cleanly?

This is my hook:

import { Message } from '@/api/models/messages'
import { messagesKey } from '@/api/queryKeys'
import { trpc } from '@/api/trpc'
import { useUserId } from '@/state/hooks'
import { db } from '@/utils/indexedDB'
import { useInfiniteQuery } from '@tanstack/react-query'

// Need this to for RQ to know type of PageParam. Otherwise it infers it as undefined based on initialPageParam.
type PageParamType =
  | {
      cursor: Date | undefined
      type: 'previous' | 'next'
    }
  | undefined

export const useMessagesInfinite = (conversationId: number | undefined) => {
  const sentBy = useUserId()

  return useInfiniteQuery({
    queryKey: messagesKey(conversationId),
    queryFn: async ({ pageParam }: { pageParam: PageParamType }) => {
      if (!sentBy) throw new Error('userId is required')
      if (!conversationId) throw new Error('conversationId is required')

      const trpcMessages = await trpc.messages.getMessages.query({
        conversationId,
        pagination: pageParam,
      })
      const indexedDBMessages = await db.getAllFromIndex(
        'messages',
        'sentBy.conversationId',
        [sentBy, conversationId],
      )
      return [...trpcMessages, ...indexedDBMessages].sort((a, b) => {
        return a.sentAt.getTime() - b.sentAt.getTime()
      })
    },
    enabled: Boolean(conversationId),
    getPreviousPageParam: (firstPage): PageParamType => {
      const cursor = firstPage.at(0)?.sentAt
      // If we don't return undefined, hasPreviousPage will always be true and it will infinitely fetch.
      if (!cursor) return undefined
      return { cursor, type: 'previous' }
    },
    getNextPageParam: (lastPage): PageParamType => {
      const cursor = lastPage.at(-1)?.sentAt
      if (!cursor) return undefined
      return { cursor, type: 'next' }
    },
    initialPageParam: undefined,
    // Have to explicitly specify type so that status is included in the data (since status is purely client-side):
    select: (data): Message[] => data.pages.flat(),
  })
}

Might be worth noting that I tried it the other way around first (i.e. newer messages were the last page, older messages were the first page). Thought maybe the first page was always supposed to be the most recent so I switched to current version, but the behavior didn't change.

My basic set up, I have an intersection observer at both the top and bottom of the scroll container. When intersection observer is in view, it triggers fetchNextPage or fetchPreviousPage if conditions are right:

import { UseInfiniteQueryResult } from '@tanstack/react-query'
import { HTMLAttributes, useEffect } from 'react'
import { useInView } from 'react-intersection-observer'

interface InfiniteScrollSentinelProps<TData>
  extends HTMLAttributes<HTMLDivElement> {
  infiniteQueryResult: UseInfiniteQueryResult<TData[]>
  type: 'previous' | 'next'
}

export const InfiniteScrollSentinel = <TData,>({
  infiniteQueryResult,
  type,
  ...props
}: InfiniteScrollSentinelProps<TData>) => {
  const {
    isFetchingNextPage,
    hasNextPage,
    fetchNextPage,
    isFetchingPreviousPage,
    hasPreviousPage,
    fetchPreviousPage,
  } = infiniteQueryResult

  const { ref: infiniteScrollSentinelRef, inView } = useInView()

  useEffect(() => {
    if (type !== 'previous') return
    if (inView && hasPreviousPage && !isFetchingPreviousPage)
      fetchPreviousPage()
  }, [type, fetchPreviousPage, hasPreviousPage, isFetchingPreviousPage, inView])

  useEffect(() => {
    if (type !== 'next') return
    if (inView && hasNextPage && !isFetchingNextPage) fetchNextPage()
  }, [type, fetchNextPage, hasNextPage, isFetchingNextPage, inView])

  return <div ref={infiniteScrollSentinelRef} {...props}></div>
}

[GarrisonBates]

I've gone through all the docs related to infinite query and I'm pretty sure this is what's going on:

1. Bottom intersection observer triggers fetchPreviousPage()
2. Page is fetched but is empty. So pages state might look like [ [], [Array(10)], [Array(10)] ]
3. Upon refresh, state's properly hydrated from local storage. Since infinite query starts from first page, it refetches the empty array. Then since getPreviousPageParam() returns undefined, that's it. No more pages are refetched, now the pages state is simply [ [] ].

So the question is really, is there any sort of built-in way to avoid this behavior? I'm pretty sure the empty array is necessary for RQ to know not to keep triggering a request every time the intersection observer comes into view, but I don't want it breaking the functionality like it's currently doing. Any ideas?

Much appreciated.

[TkDodo]

Upon refresh, state's properly hydrated from local storage. Since infinite query starts from first page, it refetches the empty array. Then since getPreviousPageParam() returns undefined, that's it. No more pages are refetched, now the pages state is simply [ [] ].

I don’t understand that. When you refresh the page, you restore from persistence, so your cache is:

[ [], [Array(10)], [Array(10)] ]

then, a refetch happens I guess? If so, we start at the first page and always call getNextPageParam, in order. If your empty page returns no nextPageParam then yes, that’s it. But it has nothing to do with getPreviousPageParam.

[GarrisonBates]

Because it's bidirectional and I was using "previous" direction to represent most recent messages (I tried both, thought maybe that was the issue but it wasn't).

Regardless, you can substitute getNextPageParam() if you like. I tried that as well. Still ends up trying to fetch first item which is an empty array, and then the chain breaks there and you end up with empty queryCache.

Thinking that maybe bidirectional scroll with max pageSize isn't the way to go. I'm leaning towards just removing maxPages and manually limiting the pages that are persisted with the shouldDehydrate property in the persister client options. And then virtualizing so performance isn't totally bricked.

[TkDodo]

shouldDehydrate only works on a per-query basis, you can’t influence the number of pages.

What’s the pageParams stored for when the pages look like this:

[ [], [Array(10)], [Array(10)] ]

when a refetch happens, we take the pageParam of the first page, invoke the queryFn, then call getNextPageParam with this page. What stops the chain from continuing is if getNextPageParam returns undefined.

[GarrisonBates]

Yeah it's undefined. Because the logic is like page.at(-1)?.cursor.

But I misspoke when I said shouldDehydrate, what I meant is serialize. Was gonna modify the query cache before serialization so that only x pages are persisted. Is there a better / built in way?