Scrolling to a dynamic height row?

[shahar-caura]

I tried using imperative methods according to the docs, but it won't scroll to row.
Any updated example?

(below is what I tried)

page.tsx

    <Example names={names}/>

Example.tsx

"use client";

import { List, useDynamicRowHeight, useListRef } from "react-window";
import { RowComponent } from "./RowComponent";
 
export function Example({ names }: { names: string[] }) {
  const rowHeight = useDynamicRowHeight({
    defaultRowHeight: 25,
  });
  const listRef = useListRef(null)

  const onClick = () => {
    const list = listRef.current;
    console.log("scrolling to row 250", list);
    list?.scrollToRow({
        align: "auto", // optional
        behavior: "auto", // optional
        index: 250
    });
    console.log("scrolled to row 250", list);
    };

  return (
    <>
    <button onClick={onClick}>Go to row 250</button>
    <List
      listRef={listRef}
      rowComponent={RowComponent}
      rowCount={names.length}
      rowHeight={rowHeight}
      rowProps={{ names }}
    />
    </>
  );
}

RowComponent.tsx

import { type RowComponentProps } from "react-window";
 
export function RowComponent({
  index,
  names,
  style
}: RowComponentProps<{
  names: string[];
}>) {
  return (
    <div className="flex items-center justify-between" style={style}> 
      {names[index]}
      <div className="text-slate-500 text-xs">{`${index + 1} of ${names.length}`}</div>
    </div>
  );
}

[havlicekdom]

I have been having the same exact issue, changing behavior to instant makes the list scroll to correct item, however the scroll position is bit off on the first scroll.

[shahar-caura]

I have been having the same exact issue, changing behavior to instant makes the list scroll to correct item, however the scroll position is bit off on the first scroll.

Have you tried calling scrollToRow twice with a short delay between? I might use it if it should work

[havlicekdom]

I have been having the same exact issue, changing behavior to instant makes the list scroll to correct item, however the scroll position is bit off on the first scroll.

Have you tried calling scrollToRow twice with a short delay between? I might use it if it should work

No, I ended up dropping react-window from the project completely as the API changed and there was no need for virtualisation in the end. Sounds like a possible work around though, as I noticed that second clicking to initiate the scroll landed perfectly on the element.

[bvaughn]

Calling it twice seems like it should work.

This does not seem like something that end users should really need to think about, so maybe the library could handle that automatically somehow

My only concern would be if we ever needed to call more than twice. I’m wary to introduce anything that might create a loop.

[ArtemBeewise]

try to wrap scroll action into requestAnimationFrame(...), like:

requestAnimationFrame(() => {
  list?.scrollToRow({
    align: 'auto', // optional
    behavior: 'auto', // optional
    index: 250,
  });
});

[fgedlek]

Hi, I’m experiencing the same issue on v2.2.3.
I’m building a chat application with variable row heights, so I’m using:

const rowHeight = useDynamicRowHeight({
  defaultRowHeight: HEIGHT_SINGLE_LINE_MESSAGE,
});

The problem appears when I’m scrolled somewhere into the list and a new message arrives whose height differs from the default.

When I call

list.scrollToRow({
  index: listData.count - 1,
  align: "smart",
   behavior,
});

the list often does not scroll far enough, leaving part of the last message hidden.
This still happens even if I wrap the call in requestAnimationFrame.

It seems related to the fact that the row’s real height is only measured once it enters the viewport, so the internal size cache is still based on the default height when the scroll happens.

Is there a recommended way to handle this scenario?
• Should the list be reset/recomputed when a row height changes?
• Or is there an intended pattern for chat-like UIs with dynamic row heights to ensure reliable scrolling to the last item?

Thanks in advance for any guidance.

[bvaughn]

I don't think there's a good way for me to improve this use case. The problem is essentially that we want to scroll to the exact location of a row that's somewhere in the middle of a bunch of other rows that we don't know the size of. The way I've built the feature uses an estimated size (based on the real sizes of rows that have already been rendered) but that can be wrong. The list could continue to retry until it eventually centers around the target row but in the worst case scenario it would need to end up (synchronously) rendering and measuring everything up to the row, which would completely defeat the purpose of windowing to begin with.

There are other ways of windowing (see here for more info) but they have drawbacks too. I think the approach I'm using here is the best option (of the ones I'm aware of).

[samuelkarani]

Yup I can also verify that scrolling from the example given DOES NOT WORK for variable rows.

[bvaughn]

For what it’s worth no one is questioning that using the imperative API to scroll to a dynamic height row isn’t reliable. I don’t know how to fix it in a way that wouldn’t kill performance and defeat the purpose of this library.

Best suggestion I can offer for now is to not combine those features. Open to ideas, though if anyone else has them.

[samuelkarani]

Ok I totally get it. I'm using react-virtuso for now as it supports this feature and I also ran into another issue with dynamic rows (unable to a set dynamic default row height with a function providing row index). However I've noticed react-window has better/smoother scrolling performance so it will be missed.

[samuelkarani]

Btw I tried the fixes mentioned above i.e. calling twice, using requestAnimationFrame, changing behavior to instant, and none worked for me. It still did not scroll. Even if it did, I would also need an offset parameter for the scrollToRow function, which seems to be missing. Or at least supporting scroll-padding-top for the scroll container (window) which I'm not sure is supported.

[fgedlek]

@bvaughn Thanks for the explanation — after my initial comment I ran a few more experiments, and while I agree this isn’t really solvable in a clean way, it does seem possible to get a reliable behavior using a workaround.

What worked for me was making multiple scrollToRow calls across several animation frames. The idea is to force the target rows to enter overscan, get measured, update the size cache, and then let following retries scroll more accurately.

A simplified version looks like this:

const SCROLL_TO_BOTTOM_RETRIES = 5;

const scrollToBottom = () => {
  if (!list || messages.length === 0) return;

  const scrollOnce = () => {
    list.scrollToRow({
      index: messages.length - 1,
      align: "smart",
      behavior: "instant",
    });
  };

  const run = (attempt: number) => {
    scrollOnce();

    if (attempt >= SCROLL_TO_BOTTOM_RETRIES) return;

    requestAnimationFrame(() => run(attempt + 1));
  };

  requestAnimationFrame(() => run(1));
};

However this is still a workaround, not a solution — and it definitely feels hacky.

@samuelkarani This might be useful for your case :)