Is it possible to cancel virtualizer's scrollToIndex?

[kristalshards]

Hello, I have encountered a situation which is as follows:

A component (let's call it Table) that is rendered receives a loading prop. If this prop is true, it returns early by rendering an indicator. If not, I am rendering a bunch of stuff, including a Container which has a ref callback attached to it and that is sent to useVirtualizer() getScrollElement and its children is another component that maps over virtualizer.getVirtualItems(). So in other words:

const Table = ({ loading, ...otherProps }) => {
  // stuff
  const someRef = useRef();
  const setRef = useCallback((ref) => { someRef.current = ref }, []);

  const virtualizer = useVirtualizer({
  // some config
  getScrollElement: () => someRef.current
  });

  if (loading) {
    return <Indicator />
  }

  return (
    // Contains more parents, but keeping the structure as simple as possible
    <Container ref={setRef}>
      <VirtualComponent getItems={virtualizer.getVirtualElements} />
    </Container>
  )
}

Upon clicking a toggle, I want to scroll to a specific index (using scrollToIndex function provided by virtualizer). Now the problem is this:

• click the toggle => the function that calculates the index runs (in a useInterval() hook, coming from react-use), virtualizer.scrollToIndex() is called, but by the time the scroll is queued (my guess, don't know how this works internally), loading is set to true, so the Container is unmounted and the ref is null. And I get this error TypeError: Cannot read properties of null (reading 'requestAnimationFrame') => coming from this:

if (this.isDynamicMode()) {
  this.targetWindow.requestAnimationFrame(verify);
}

My question, is it possible to cancel this scrollToIndex function once it's initiated? Or how can I think as a mental model to fix this issue?

[piecyk]

Right now, scrollToIndex doesn’t expose a cancellation mechanism. Internally it schedules scroll work (e.g. via requestAnimationFrame for dynamic lists or smooth behavior), and if the scroll element is removed before that runs, it can blow up as you observed.

That’s something we should fix on our side, if there’s no scroll container anymore, the scroll should simply be a no-op rather than throwing.

Also worth noting: you can always implement your own “scroll to index” on top of the virtualizer (compute the offset and call scrollTo directly), which gives you full control over cancellation/guards if you need it.