onRangeChange alternative OK to call unthrottled onScroll?

[aeharding]

Hi!

I used onRangeChange extensively with voyager. https://github.com/aeharding/voyager The main purpose was to know when an item has been scrolled past, to mark as read.

Now I see it is recommended to call handle.startIndex/endIndex.

However doesn't that call findIndex which isn't efficient to be called onScroll? I don't want to throttle if I can avoid it, because that might miss quickly scrolling down and up again.

I just want to check what is recommended. I try to avoid scroll linked computations for performance reasons :)

[aeharding]

Well, this is my best attempt. Unfortunately, the throttle loses some range changes though. Does anyone else have other ideas?

import { useThrottledCallback } from "@mantine/hooks";
import { useRef } from "react";
import { VListHandle } from "virtua";

export function useRangeChange(
  virtuaHandleRef: React.RefObject<VListHandle>,
  onRangeChange: (startIndex: number, endIndex: number) => void,
) {
  const startIndexRef = useRef(-1);
  const endIndexRef = useRef(-1);

  return useThrottledCallback(function onScroll() {
    const virtuaHandle = virtuaHandleRef.current;

    if (!virtuaHandle) return;
    const { startIndex, endIndex } = virtuaHandle;

    if (
      startIndex !== startIndexRef.current ||
      endIndex !== endIndexRef.current
    ) {
      onRangeChange(startIndex, endIndex);
    }
    startIndexRef.current = startIndex;
    endIndexRef.current = endIndex;
  }, 200);
}

[aeharding]

Here is the usage aeharding/voyager@af9ffd3

[inokawa]

Throttling will improve perf, but I think it's not necessary for most cases.

In theory, React will render virtualizer once (sometimes batched or called twice for bailout though) on each scroll event. The startIndex and endIndex with overscan will be searched on render using the findIndex, so one scroll costs roughly 2. If you call handle.startIndex in onScroll, the total cost will be roughly 3.

The findIndex was re-implemented with binary search in 0.35.1 so it's fast enough to be called several times. And this total design was inspired by react-window, which search startIndex and endIndex once on render or twice if range change callback is specified.

Yes, of course throttling is better if it fits the usecase. And maybe we can implement memoization for findIndex call in virtualizer internally, but probabaly it can be complex for dynamic sized virtualizer.

[aeharding]

Thanks!

Perhaps a couple suggestions:

1. Make startIndex and endIndex getters into functions - findStartIndex() and findEndIndex() (or getStartIndex(), although find might be more accurate for what is happening under the hood). The reason being since these are not O(1) calls a developer might do this:

for (let item of items) {
  if (vHandle.startIndex > 0) {
    // do thing
  }
}

Which seems totally fine but has a lot of potential perf issues because it is not obvious that vHandle.startIndex is not O(1) - especially if it was done inside an onScroll

I'd be happy to contribute a PR for this - would you accept?

2. Expose onLayout callback

I understand onRangeChange was removed, but perhaps it would be possible for Virtua to expose onLayout, with no cb params. Virtua would basically fire any time it does any dom updates. Even if it is called a lot, it would probably be called less than onScroll Would it be a lot of work to expose? I'm curious what you think.

[inokawa]

Thank you for the suggestions!

1. findStartIndex() and findEndIndex()

"find" seems better than "get". Yes, PR welcome!

2. Expose onLayout callback

Actually, Virtua doesn't know dom is updated or not. By design, Virtua knows when to check update (resized, scrolled, children changed, etc.), but doesn't know the actual result and diffing algorithm of React (or Vue/Solid/Svelte) only knows it.

We can detect it using MutationObserver in userland but I would not recommended it because accessing dom can decrease perf than accessing cache in JS... Also, we can expose callback for useEffect or useLayoutEffect as on render callback, but usually it will be frequently called than onScroll because it handles resize, scrollEnd, children change, etc not only scroll.

[aeharding]

Ahh, I think I fully understand, thanks for the reply. I'll make a PR for 1 soon.