import React, { Component } from 'react';
import './App.css';
import '../node_modules/@blueprintjs/core/dist/blueprint.css';
import '../node_modules/@blueprintjs/table/dist/table.css';
import {Cell, Column, Table, RenderMode} from '@blueprintjs/table';
const columns = ['a', 'b', 'c', 'd', 'e', 'f', 'g'];
class App extends Component {
renderCell = (rowIndex) => {
return (<Cell key={rowIndex}>ABC</Cell>);
}
render() {
return (
<div className="App">
<Table
renderMode={RenderMode.NONE}
numRows={2000}>
{columns.map((c) => {
return (<Column key={c} renderCell={this.renderCell}/>);
})}
</Table>
</div>
);
}
}
export default App;
"@blueprintjs/core": "1.30.0",
"@blueprintjs/table": "1.27.0",

"@blueprintjs/core": "1.28.0",
"@blueprintjs/table": "1.25.0",

This change started in 1.26 and is present in 1.27 as well. I am hoping RenderMode.NONE will continue to offer "gapless" scrolling but tbh I haven't kept up with the changelog as well I should be so I am not sure if something changed by design.
Not quite sure what to make of this at a glance, but I'll look into it.
@cmslewis we can play with the number of rows/cols in the buffer
@cmslewis @llorca curious on the priority and/or timeline for addressing this – also what are your thoughts are on the original behavior (circa Table 1.25), i.e. which behavior is "correct" in your eyes?
I am stuck on 1.25 until this is resolved - trying to plan for a worst-case scenario 😅
@sighrobot no timeline, sorry. I know it doesn't look amazing, but you'll want it anyway for all the performance improvements that it brings.
Have you tried tweaking the values from the batcher? Try increasing some of these and see it makes things better. If none of that works, you can always go back to RenderMode.NONE to get rid of the batching behavior
@llorca thank you for the batcher value suggestion! I will start to play with that.
However the reason why I opened this issue in the first place was to highlight the fact that RenderMode.NONE does not "get rid of the batching behavior" in 1.27 or later (at least it doesn't seem to visually), as per my GIFs above.
Any update on this? I'm getting similar results.
@orrybaram fwiw I have not upgraded since 1.27 – I've been unable to achieve anything close to the old behavior through changing the batcher values.
Bummer
Could this be related to #1974?
It's not just during scrolling, when I stop scrolling it usually ends up like this:

Or like this:

So it's not usable as is. I wouldn't mind some blinking during scroll, but these are images after stopping scrolling.
Google Chrome.
P.S. I wonder does different scrolling behaviors affect this? E.g. in Windows the scrolling happens in steps, but I suspect with macOS and mobile devices it's by pixel.
I am having the same issue as @Ciantic when scrolling in Chrome in a medium sized table (400 rows). The scrolling itself is choppy, and sometimes when scroll has ended no rows are rendered.
I tried with all renderModes

I'll investigate more this afternoon.
I have also ran into this issue with ~10 columns and only 100 rows. Is there away to not have to render the cell every time the user scrolls?
Any update on this issue ...
Any update on this issue .. @adidahiya @giladgray @cmslewis
This is an old issue and feels outdated... there are other more recent table rendering issues to focus on, I think we should close this and instead look at / comment on issues in the table 3.8.x milestone. Try using table 3.7.x, and if you still have the problem in this thread, please file a new issue.