Back

Live Mode

Live Mode
MK
Maximilian Kaske
7 min read
engineering

This article is part of the logs.run series.

You can enable the live mode right away via logs.run/i?live=true.

Note that it's a demo. The data is mocked and not persisted. Live mode might take a while to load new data.

While TanStack provides excellent documentation on Infinite Queries, this article offers an additional practical example focusing on implementing a live data update.

Basic Concept

Infinite queries work with "pages" of data. Each time you load new data, a new "page" is either appended (load more older data) or prepended (live mode newer data) to the data.pages array defined by the useInfiniteQuery hook. In the documentation, you'll read lastPage and firstPage to refer to the last and first page respectively.

Each query to our API endpoint requires two key parameters:

  1. A cursor - a pointer indicating a position in the dataset
  2. A direction - specifying whether to fetch data before or after the cursor ("prev" or "next")

A timeline sketch of the infinite query behavior:

Timeline with live mode and load more behavior

  • The nextCursor is the timestamp of the last item of the page. The "next" page will only fetch items that are older than the nextCursor.
  • The prevCursor is the timestamp of the first item of the page (or the current timestamp). The "prev" page will only fetch items that are newer than the prevCursor.

API Endpoint

Your API endpoint should return at minimum:

When fetching older pages ("next" direction), we set a LIMIT clause (e.g., 40 items). However, when fetching newer data ("prev" direction), we return all data between the prevCursor and Date.now().

Let's take a look at an example implementation of the API endpoint:

Key points:

  • Live mode ("prev" direction): Returns all new data between Date.now() and the cursor from the first page
  • Load more ("next" direction): Returns 40 items before the cursor of the last page and updates nextCursor

Important: Be careful with timestamp boundaries. If items share the same timestamp, you might miss data because of the > comparison. To prevent data loss, include all items sharing the same timestamp as the last item in your query.

Avoid Using OFFSET with Frequent Data Updates in Non-Live Mode

While it might be tempting to use the cursor as an OFFSET for pagination (e.g. ?cursor=1, ?cursor=2, ...), the following approach can cause problems when data is frequently prepended:

When new items are prepended, they shift the offset values, causing duplicate items in subsequent queries.

Offset caveat example

Client Implementation

Let's call our API endpoint from the client and use the dedicated infinite query functions that are added to the useQuery hook.

The getPreviousPageParam and getNextPageParam functions receive the first and last pages respectively as their first parameter. This allows us to access the return values from the API, prevCursor and nextCursor and to track our position of the cursor in the dataset.

TanStack provides helpful states like isFetchingNextPage and isFetchingPreviousPage for loading indicators, as well as hasNextPage and hasPreviousPage to check for available pages - especially useful for as we can hit the end of the load more values. Check out the useInfiniteQuery docs for more details.

Both fetchNextPage and fetchPreviousPage can run independently and in parallel. TanStack Query manages appending and prepending pages to the data.pages array accordingly.

Implementing Auto-Refresh

While TanStack Query provides a refetchInterval option, it would refetch all pages, growing increasingly expensive as more pages are loaded. Additionally, it doesn't reflect the purpose of live mode as instead of refreshing the data, we want to fetch newer data.

Therefore, we implement a custom refresh mechanism for fetching only new data that you can add to any client component. Here's an simple example implementation of the LiveModeButton:

We use setTimeout with recursion rather than setInterval to ensure each refresh only starts after the previous one completes. This prevents multiple simultaneous fetches when network latency exceeds the refresh interval and is a better UX.


Go check it out on logs.run/i?live=true.

For more details about our data table implementation, check out The React data-table I always wanted blog post.