React-virtualized: Table: overscanRowCount in the reverse of scrolling direction

[JonathanMerklin]

Background

I'm working through an issue where one of my team's UI components that uses the react-virtualized table under the hood is making rows disappear from the top of the table as you scroll down the page. I'm presuming the real crux of the issue is with our team's implementation/usage of WindowScroller and AutoSizer, but even by playing with passing through the overscanRowCount to match the static number of rows in my table only appears to work in the scrolling direction - which is documented, so I'm not upset about it.

(Aside: Obviously, since I mentioned my row count is static, the real solution is "well, wait, why are you using react-virtualized then?" but I've been told that for maintainability, I should conform to our UI library and enhance that instead of going rogue and just putting together a <table></table> for the application I'm working on. I really could go on about this, but this feature request shouldn't be coupled to my team's internal politics 😄. )

I'm hoping that this feature request is relatively quick to implement as I imagine the logic would mirror that of the existing overscanRowCount and if I find the time to dive into your codebase, I could try whipping up a PR myself, but that'd be "somewhat near, but not immediate future".

Formal Feature Request information

• Use case: Application with a table with a known maximum row quantity will occasionally not render uppermost rows of table when scrolling down, and vice versa. A stopgap for "reverse overscanRowCount" would solve the problem at a (hopefully) smaller time cost than AutoSizer implementation debugging.

• Proposed interface:

<Table
    overscanRowCountReverse={n}
    {...otherProps}
/>

• Similar Functionality Example: Can't think of any off the top of my head, sorry.

[JonathanMerklin]

Also, for my specific use case, this would work:

<Table
    __dangerouslyOverscanAllRows={true}
    {...otherProps}
/>

which of course generally nukes the performance and should not be recommended at all, but would also be (presumably?) easy to implement as you'd just effectively set overscanStartIndex: 0, overscanStopIndex: rows.length // if 0 rows is handled somewhere else and/or this is for loop-y but you get the idea

[JonathanMerklin]

Just figured I'd update here, in case anyone else is running into the same issue for the same reasons as me.

After looking through some of the codebase for the preliminary steps towards writing a PR, I found and was able to use the undocumented/almost-definitely-not-kosher prop overscanIndicesGetter, which - when I tell our "wrapper component" I need to __dangerouslyOverscanAllRows, I pass as:

additionalTableProps.overscanIndicesGetter = function({
    cellCount,
    overscanCellsCount,
    scrollDirection,
    startIndex,
    stopIndex
}) {
    return ({
        overscanStartIndex: 0,
        overscanStopIndex: cellCount-1
    });
};

EDIT: Whoops, didn't mean to close just because I'd worked around my problem; clicked the wrong button. Reopening.

[wuweiweiwu]

@JonathanMerklin I apologize for not getting to this earlier. Thanks for posting the work around.

However, I think we can also be a little big greedier when rendering rows in the opposite direction of scroll.

[slashwhatever]

I get the same issue right now...but only when the number of rows is small i.e. smaller than a "page"