A more accurate getEstimatedTotalWidth

[tanin47]

Hello! Thank you for writing up such a wonderful library. I've been using VariableSizeGrid with react-virtualized-auto-sizer. I know the set of columns and their widths upfront.

I notice that, when there are many columns and I scroll to the right, it seems the initial scroll bar's width isn't accurate. The scroll bar's width jump to a completely new position once I scroll to the right most part.

I've found a fix for it, but I'm unable to tell why the previous code doesn't work: https://github.com/bvaughn/react-window/pull/811/files#diff-b0f813b993eaf874b282e409315e0a2348229d2f79fd9ee5fde673f5bfa127a9

With the fix, the initial scroll bar's width would be correct. When scrolling to the right most part, the scrollbar's width and its position don't jump.

If there's nothing obvious, I can build a PoC for it. I just wanted to open an issue first. Thank you.

[bvaughn]

Hi @tanin47. Thanks for the comment and the link to the diff.

The code your change has deleted is there to avoid the overhead of having to eagerly measure every column or row in a large grid. (For example, let's say you have a list that's 10,000 rows long. I'm trying to avoid having to eagerly call the getItemSize function 1,000 times just to render the grid initially because (a) this function is user code and it might actually be doing something expensive and (b) in most cases, lists are rendered initially with an offset of 0 and so an estimated total height is sufficient for a scrollbar. As the user scrolls, the list keeps track of how far it has measured and refines the overall size (which can cause the scrollbar size to change but generally this change is gradual and not very noticeable over time).

Your proposed change would make the initial scrollbar size accurate but come with a potentially large performance cost. The recommendation I would normally make for people in the position you've described would be to try to provide a more accurate estimatedColumnWidth value. (I assume the default value of 50px is way off from your actual column sizes from the sound of it).

Let me know your thoughts!

[tanin47]

The app estimates width of each column based on the data inside. I'l try estimatedColumnWidth. Thank you.

As a side note, I use this patch with ~4M rows + ~50 columns in an electron app where it loads and queries large CSVs, and I don't experience any slowness.

Thank you so much. I'll use the option you mentioned.

[bvaughn]

Let me know if it works!

[tanin47]

It doesn't quite work because, if I understand correctly, estimatedColumnWidth is a single estimate for every column. In my case, I know each column's width specifically.

If there's a way to provide: estimatedTotalWidth, that would work for me.

[bvaughn]

If there's a way to provide: estimatedTotalWidth, that would work for me.

That's not a prop I want to add to this library. This use case kind of falls between the cracks of what I was aiming to support here. My suggestion would be to just use the innerElementType to override the estimated scrollable width. That prop is meant as kind of an escape hatch for more advanced use cases.

function InnerElementType({ style, ...rest }) {
  return (
    <div
      data-testid="example"
      style={{
        ...style,
        width: 100_000, // Whatever your width is
      }}
      {...rest}
    />
  );
}

[tanin47]

This works. Thank you so much.

[bvaughn]

No problem! 😌 Glad to hear it

…

On Sun, Apr 27, 2025 at 5:10 PM Tanin Na Nakorn ***@***.***> wrote: *tanin47* left a comment (bvaughn/react-window#812) <#812 (comment)> This works. Thank you so much. — Reply to this email directly, view it on GitHub <#812 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHHHL72ORXSO463B2LKBL23VBVBAVCNFSM6AAAAAB2R6ANTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZTGY2DEMBTGA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>