2024/04/29/modern-react-virtual-scroll-grid-9

[utterances-bot]

Modern React Virtual Scroll Grid 9 : Fixing SlickGrid

Last time we integrated SlickGrid’s paged scrolling system and found that it came really close to working well.

https://www.thecandidstartup.org/2024/04/29/modern-react-virtual-scroll-grid-9.html

[ghiscoding]

Hello, I'm a maintainer of SlickGrid. This is an interesting article that I found on Google and I was wondering if you were considering to eventually contribute to the project itself? However, I do think that the small list scroll jumping (when using the scroll arrow with the mouse) would have to be fixed before merging your code into SlickGrid but it's very interesting nonetheless so I hope you would consider contributing.

The scroll jumping problem reminds me of another lib that I support multiple-select-vanilla (which is also a fork), it's another lib that I use in Slickgrid-Universal and this ms-select also has a virtual scroll that you can see in this Example. I remember having a similar scroll jumping problem when I was jumping from the bottom of the scroll to the top of the scroll every time I switched to the next virtual page and I think the way I've fixed it (I don't fully recall) was to calculate the scrollTop position and reapply it when moving to the next page and the calculation involves knowing the row height (which we do know in SlickGrid).

Anyway, it would be great if again you would consider contributing and/or open a Discussion in SlickGrid to discuss it. Cheers

[timwiegand]

Thanks for reading and commenting. The small list control is a hack where I've force enabled the paged scrolling behavior for a small sample so it's easier to understand what's going on. In the normal build, like in SlickGrid, paged scrolling isn't enabled unless you have a container bigger than six million pixels. At that size, again like in SlickGrid, you can hardly notice the scrollbar thumb jumping back.

The previous post goes into more detail on the issues I found with SlickGrid's paged scrolling algorithm.

I don't use SlickGrid as I need something that will support millions of rows and columns. Which is how I ended up building my own controls. I did think about contributing to SlickGrid but I couldn't see any practical way to add support for large numbers of columns.

I'd be happy to open a discussion if I can reproduce the issues in SlickGrid. Is there an online example that lets you control the number of rows and jump to a specific item? I think it'll need at least 25 million rows before you see any problems.

[ghiscoding]

SlickGrid has a few Examples but they are static and not editable from the website, you can run them locally though if you clone the repo. The Highlighting & Flashing example has a "jump to server", apart from that there's the Grouping example that has buttons change dataset length (50/50K/500K) but there's no example to show exactly what you want but new examples could be added.

I did read both of your posts but rather quickly, another thing I've noticed in your page demo is that the super large demo (trillion of rows), dragging the scroll will make it jump rather quickly and there's no way to be really precise (for example, scroll to row 2000, you might be lucky but in most cases you won't be), nonetheless it's nice to see the power of SlickGrid and its usage of virtual-scroll. I remember that there was 1 user who said he had billion of rows but I have never tried this myself since in most cases I would turn to backend services with pagination to load that many without impacting the user.

[timwiegand]

There's a limited number of pixels you can move the scroll bar to, in that sample around 200, so you'll jump about 5 billion rows for every pixel you drag. In theory, you can then be more precise by using the page up/down keys or arrow keys to move a page or row at a time. Of course it would take forever to scroll through 5 billion rows.

Any real app with lots of rows needs a "Scroll to item" field so the user can jump to where they want to go. You also need to virtualize all the way back to the server and download data on demand to populate the currently visible rows.

It would be generally useful to have a SlickGrid example with a field that let's you specify the number of rows in the grid, together with a "scroll to item" field. Would make it easy for potential users to understand how well SlickGrid scales to their use case.

[ghiscoding]

Ok I see, that makes sense and I guess that the user will probably start filtering if he really wants to see a particular set of data instead of scrolling.

I would suggest you to clone the repo and add a new example with that theory in mind 😉 I'm wondering if perhaps we could/should have your code as a new grid option to use either the default scroll or the one you worked on. I'm saying this because like you said, your code seems to be more useful with millions of rows and less useful (or precise) with smaller set of data, so an opt-in feature might be better in this case!?

I'll cc @6pac since this might interest him as well, Ben if you read this thread then I would suggest you read the great article that @timwiegand wrote here: Modern React Virtual Scroll Grid 9 : Fixing SlickGrid

I find the subject interesting and I think that we're always open to any code change that could improve the project UI/UX especially.

[timwiegand]

The overall experience is the same as SlickGrid today. All I've done is fix some edge cases in SlickGrid's algorithm. If only you had that large row count example you could see for yourself :-)

I don't have time right now to get up to speed with SlickGrid and create an example. I might come back to it in a couple of weeks but no promises.

[6pac]

Interesting. I've been asked to quote on building several features for SlickGrid, one being variable row height (which I've been thinking on for a while). That will involve this part of the code, so I'll keep this discussion in mind.

[timwiegand]

@6pac You might be interested in this post which covers my approach to variable size items.

[6pac]

Wow. Well, you've just done my work for me! This was precisely the approach I was planning on - assuming there will only be a smaller number of different-size rows, maintiaing an array of sizes for just those items, and an algorithm to work out where in the total row space we are, and use a combination of multiplied standard row size and size info from the array to get an offset (with possible offset caching in the array). My other task is to work out the UI implications of different-sized rows, but I think that will be relatively straightforward.