Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upper limit on number of rows? #108

Closed
delateurj opened this issue Dec 14, 2018 · 3 comments
Closed

Upper limit on number of rows? #108

delateurj opened this issue Dec 14, 2018 · 3 comments
Labels
💬 question Further information is requested

Comments

@delateurj
Copy link

delateurj commented Dec 14, 2018

Hi,
Thanks for your work on this. I was doing a little testing of how very long lists are handled.
I noticed that in the example Fixed Sized Grid in code sandbox it will only handle a row count up to 958698. Any value greater than that and it does not display rows beyond row 958698 (index 958697). I am not surprised there is some upper limit just due to memory and variable maximums, just wondering if this level was surprising and if one can estimate the upper limit of rows/cells.
Thanks.

@delateurj
Copy link
Author

delateurj commented Dec 14, 2018

Did a search over in react-virtualized and I think this issue bvaughn/react-virtualized#193 (comment) is the same question and I see its related to maximum number of pixels supported by the browser...so I'll close this. Please reopen if you think this should be different in react-window. Sorry I didn't look in react-virtualized first.

@bvaughn bvaughn added the 💬 question Further information is requested label Dec 14, 2018
@bvaughn
Copy link
Owner

bvaughn commented Dec 14, 2018

Hey @delateurj! The issue you linked to (bvaughn/react-virtualized/issues/193) is definitely related. Browsers have a maximum pixel size that they support. For newer browsers, that pixel limit is really high.

In react-virtualized, I implemented a workaround for this (ScalingCellSizeAndPositionManager) but abstractions add cost both in terms of maintenance and runtime performance, and I decided against adding a similar workaround in react-window.

My main reasons for this decision were:

  1. Newer browsers have a much higher pixel threshold so this is becoming less of an issue over time.
  2. The user experience of in-browser lists that exceed this threshold is arguably poor to begin with. It's conceptually nice to be to render a list of one million items, but it's not practical to load so much data on the client, and it's not user friendly to make people scroll through such large lists without some sort of secondary filtering/sorting controls.

Hope this explanation makes sense and is useful to others who come across this issue in the future.

@delateurj
Copy link
Author

Thanks. Decision/explanation makes sense...was exploring the edges.

scott-fleischman added a commit to ancientlanguage/visualize-bits that referenced this issue Oct 10, 2019
p12tic added a commit to p12tic/buildbot that referenced this issue Aug 21, 2023
Buildbot must support rendering large logs of potentially millions of
lines. Log viewer is currently implemented by showing a div with the
height equal to line_height * number_of_log_lines, just not displaying
the log lines themselves. Unfortunately browsers don't support large
HTML elements like this and start misbehaving when the number of log
lines is in hundreds of thousands.

Unfortunately react-window does not support any workarounds for this
problem and does not plan to do so
(bvaughn/react-window#108 (comment)).
react-virtualized had other issues, so the workaround is to fork
react-window and implement the fix ourselves.

As a bonus, there have been buildbot-specific hacks to react-window
already, so now these can be implemented properly.

Note that this commit adds a version of react-window which is already
heavily modified to use typescript instead of flow type checker.
Patterns not supported by typescript have been removed.
pmisik pushed a commit to pmisik/buildbot that referenced this issue Sep 6, 2023
Buildbot must support rendering large logs of potentially millions of
lines. Log viewer is currently implemented by showing a div with the
height equal to line_height * number_of_log_lines, just not displaying
the log lines themselves. Unfortunately browsers don't support large
HTML elements like this and start misbehaving when the number of log
lines is in hundreds of thousands.

Unfortunately react-window does not support any workarounds for this
problem and does not plan to do so
(bvaughn/react-window#108 (comment)).
react-virtualized had other issues, so the workaround is to fork
react-window and implement the fix ourselves.

As a bonus, there have been buildbot-specific hacks to react-window
already, so now these can be implemented properly.

Note that this commit adds a version of react-window which is already
heavily modified to use typescript instead of flow type checker.
Patterns not supported by typescript have been removed.
slydiman pushed a commit to gkistanova/buildbot that referenced this issue Sep 30, 2023
Buildbot must support rendering large logs of potentially millions of
lines. Log viewer is currently implemented by showing a div with the
height equal to line_height * number_of_log_lines, just not displaying
the log lines themselves. Unfortunately browsers don't support large
HTML elements like this and start misbehaving when the number of log
lines is in hundreds of thousands.

Unfortunately react-window does not support any workarounds for this
problem and does not plan to do so
(bvaughn/react-window#108 (comment)).
react-virtualized had other issues, so the workaround is to fork
react-window and implement the fix ourselves.

As a bonus, there have been buildbot-specific hacks to react-window
already, so now these can be implemented properly.

Note that this commit adds a version of react-window which is already
heavily modified to use typescript instead of flow type checker.
Patterns not supported by typescript have been removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💬 question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants