React-virtualized: [STICKY] Tell me how you're using react-virtualized

[bvaughn]

A better understanding of how react-virtualized is being used will help me better prioritize features and shape the roadmap going forward. So if you're using this project, I'd love for you to leave a comment and tell me the following:

1. What are you using react-virtualized for (eg. form controls, data grids, etc)?
2. Which component(s) do you find most useful?
3. (Optional) What product(s) / project(s) are you using react-virtualized in?

[felipeleusin]

HI,

First I would like to thank you for this project, it helped a lot when we had to work with some larger datasets.

1. We're using virtualized for data grids and large tables.
2. We had trouble using the built-in Editors, specially it would be good to export the EditorBase class so we can extend upon it. Also on mobile we noticed some performance degradation when using FlexTable (due to flexbox performance) so we instead switched to using a Grid with only one column and styling using regular float or inline-block. This was purely a perception (no idea how to benchmark this kind of thing) when testing in Android design and since it was an easy change in our use case.

[bvaughn]

Thanks for being the first to reply @felipeleusin! Much appreciated. :)

I also appreciate the note about flexbox performance on mobile. That's a good thing for me to potentially add to docs somewhere.

[fermuch]

I'd like to thank you for building such an awesome project. I've been using it since today, so my comment might not be as useful.

1. Large lists of items. We have over 9000 items in a single list with different heights each, and using pagination was not an option.
2. First I tried the InfiniteLoader. Using it was simple, and I really liked it, but most of the data was already on the client, so I VirtualScroll. I am surprised for how simple it is to set it up.

As of now, I don't really have anything to complain. The docs are clean and simple, the examples are short and concise.

[bvaughn]

Thanks for the kind words @fermuch. I'm glad to hear that you're finding the library easy to work with!

[wmertens]

We're considering to use it for virtual scrolling through 200+ news items with variable height but right now we can't really use it because the API doesn't allow notifying of height changes after a row was rendered, or am I wrong?

[fermuch]

@wmertens the heights in my list are variable. I have it like this:

                <AutoSizer>
                  {({height, width}) => (
                    <VirtualScroll
                      width={width}
                      height={height}
                      rowsCount={markers.length}
                      rowHeight={(index) => {
                        const marker = markers[index];
                        if (selectedMarker === marker._id) {
                          return 225;
                        }
                        return 110;
                      }}
                      ...

[wmertens]

@fermuch I would like to have variable-height-determined-by-browser rows, meaning that each row is laid out by the browser and that determines its rowHeight.

With the current API that is not really possible I think, except by using something that forces a redraw of the VirtualScroll element after the correct row height is determined.

[fermuch]

Oh, I am not sure how to do that. You need to calculate how much rows are visible? Maybe an option to pass how many items are currently rendered would be a good idea?

[bvaughn]

@fermuch, @wmertens: Let's move this discussion off of this GH issue. I opened this issue for a very specific reason. (I want to know how react-virtualized _is being used_.) Feature requests and trouble-shooting can be done one other, more focused issues (in this case maybe #149).

[kasrak]

Thanks for react-virtualized! We're using an internal fork of Grid for rendering a few different parts of the UI in Airtable. e.g. in embedded card lists, like this one: https://airtable.com/whatsnew

We ended up forking because we needed more control over the actual DOM elements being emitted. Our component is only responsible for dynamic drawing and delegates the layout and rendering of individual items to a provider. Decoupling dynamic drawing from layout also makes it easy for us to reuse the component for arbitrary layouts in the future.

The layout provider's interface is basically these 4 methods:

 - getNumberOfItems()
 - getVisibleItemIndicesInRect(rect)
 - getContentSize(containerSize)
 - getComponentForItemAtIndex(itemIndex, containerSize)

If you want to chat about this more, feel free to email me at [email protected]!

[andevsoftware]

@kasrak I agree. I end up forking the Grid component too because I want more control over the way the items are rendered in the given visible boundaries. I think the delegate pattern is not too hard to implement looking at the way how the Grid component is set up atm. In my case I want to render items in a grid for example, see below. Would you mind giving an example of how the provider is set up?

[andevsoftware]

Perhaps https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionView_class/ can give more insight on this.

[bvaughn]

FWIW I am interested in react-virtualized supporting the kind of flexible use-case described by @kasrak and @olivierandriessen. Let's work together to make that happen. :)

[bvaughn]

FYI @kasrak - @olivierandriessen and I chatted on Hangout a bit ago and I created issue #181. The conversation gave me an idea for a small change or two that I could make to Grid to make it a bit more customizable out of the box. If you're available sometime soon, maybe we could chat briefly as well so I could get a better sense of your use cases too.

[bvaughn]

FYI, I've filed issue #182 as well after a discussion with @kasrak. Goal is to support custom (non-checkerboard) layouts. Feedback welcome!

[bvaughn]

FYI @olivierandriessen release 6.1.0 supports a custom renderCellRanges property for Grid. Hope you're able to use it for your spreadsheet app.

[nishp1]

Brian, thanks for working on making the integration with react-select super easy!

I am going to be using this library along with react-select to work on custom dropdowns with large datasets, nested expandable options, sectioned options (think optgroup).

[oyeanuj]

Would like to really use it for a feed of stories with dynamic, non-predictable heights (similar to say that of Facebook) :)

[bvaughn]

@oyeanuj Let's chat about that on #149? :)

[ifunk]

We're using it to display thousands of thumbnail images in a grid. Works really well with Autosizer and Grid components... thanks!

[cpinnix]

We're using VirtualScroll for large document images. One thing I'm looking for is the ability to know when scrolling has stopped to avoid loading large images in between a large scroll. Similar to FixedDataTable's onScrollEnd. Thinking about a solution now and open to solutions as well.

[bvaughn]

@cpinnix: Sounds like you could just use a debounced onSectionRendered callback for that?

[cpinnix]

@bvaughn Yeah. Right after posting I came up with a simple timeout solution.

const delay = 500;
let timeout = null;

...

_onScroll(data) {
  clearTimeout(timeout);
  timeout = setTimeout(() => {
    this.props.onScrollEnd(data.clientHeight, data.scrollHeight, data.scrollTop);
  }, delay);
}

[MikeMcElroy]

We've settled on RV for our big React-based work project, and we've just settled on a series of patterns for our uses. We have chosen patterns for our tables, so a lot of options are unnecessarily verbose, and we didn't want to have to educate our devs on all of the features, so we decided to build a small DSL which simplifies about 75% of the usage of FlexTable/FlexColumn.

Issues:

• Inline styling story (of course, having discussed this in #205)
• HeaderRenderer -- Needing to specify a headerRenderer on each column is an annoyance, when most of them are the same or at least dependent on whether or not the column is sortable.
• Non-named function arguments. Obviously, I'm glad to see these going away in the next big version.
• Expand/Collapse a row. If a row is truncated, it would be cool to be able to expand it out to its full size and push the row height down.
• A nicer sorting story. Since sorting is done at the column level, it would be interesting to have something like a function which acts as a sorter at the column level-- something that would be passed to the sort method on the table to simplify or generalize the sorting function outside of the table. If it were put in words, it would be something like "Here is the column to sort on, and this is how you sort it".

That said, I really like all the work that's been done on RV in the past, and am looking forward to seeing it improve (and helping where I can).

[bvaughn]

Happy to hear that you've chosen to go with RV Mike! I think we can definitely improve a few of the points you've mentioned. Welcome onboard. :)

[smitch88]

I've been using RV in the clojurescript world and just added a PR into cljsjs package repo so it can be included as a dependency a bit easier for cljs builds.

https://github.com/cljsjs/packages/pull/544

I was using fixed-data-tables but I like your generic row buffering component VirtualScroll so I'm building a couple wrapper components around that and utilizing your FlexTable for some data grids.

My main Issues but not really blockers:

FlexTable

• Group headers
• Fixed columns

For the group headers, I have just wrapped a FlexTable with a container div + header div broken up as I need. I have no workaround for the fixed columns issue but it isnt a hard requirement for me at the moment.

[clauderic]

Hey there,

Thought I'd chime in since I've been using React Virtualized for a while now. I'd like to start off with a massive thank you. This project has truly been a godsend. In my experience, I've found it to perform a lot better than the other react virtual scrolling solutions out there 👍

I've been using the React Virtualized VirtualScroll component at work in a production to-do app built with Cordova and released for iOS and Android to render large lists of to-do's. I had to write my own sorting library, which came with it's own set of challenges, but the end-result is fantastic and the performance boost was massive. Gif doesn't really do it justice, but here's what it looks like (nevermind the dummy data 🙈)

We also opted for React Virtualized when the time came to revamp the date-picker in the app. We used it to create an infinite scrolling date-picker component, which we recently decided to open-source. I don't believe there is anything out there quite like it for React and we felt the community might benefit from it.

In terms of improvements, are there any plans for supporting relative positioning for VirtualScroll elements? As well, I agree with @smitch88, Fixed headers would be a really nice feature, especially for mobile apps using RV

[bvaughn]

Fantastic, @clauderic! Thanks for sharing the videos. I love seeing what you've done with RV!

react-infinite-calendar in particular is slick! Just gave it a shout-out on Twitter. :)

The drag-and-drop UI is also very cool. Would love to see how you're implementing that. I get asked about that pretty regularly but up until this point, I haven't had to build it- so my recommendations are...vague. :D

[clauderic]

@bvaughn Thanks man, glad you appreciate it! And thanks for the shoutout! 😊

As for drag and drop... It was quite an interesting challenge to solve. Anytime elements come in and out of the DOM, you have to re-build the list of elements that will be animated as they get hovered over and keep track of their actual index in a data-attribute or something of the sort (as opposed to their index in the DOM). The logic is pretty straightforward on desktop, with translate3d animations and auto-scrolling. But on mobile it proved to be a lot more challenging, since touch events stop firing when the event.target element is removed from the dom (which inevitably happens when you start scrolling). Had to get pretty creative...

It's probably one of the next projects I'll work on open sourcing, but the code is pretty messy at the moment since it's tightly coupled with the app and is intertwined with pull to refresh and swipe actions.

[bvaughn]

If you do open-source it at some point, point me at it! I'd love to see it. :)

[abhirathore2006]

@bvaughn i am using react-virtualized in a search page, however i have small issue actually more over a request, now it creates its own container, is it possible to make it use the same window scrollbar ... like this https://react.rocks/example/react-virtual-list because i have other content too and showing multiple scroll-bar doesn't look good

i believe this will make it a perfect solution.

[SteveKennedy]

@clauderic I know this is off topic, but can you point me to where I can find that to-do list manager? I can't find it on Android, and I've been looking to try new ones.

[clauderic]

@bvaughn Finally open-sourced the sortable higher-order component 🎉 It's still fairly experimental, but if you're looking for a dead-simple solution to add sortable functionality to your existing components or to a react-virtualized list, might be a decent option :) It also supports touch devices out of the box, and has a tiny footprint. https://github.com/clauderic/react-sortable-hoc

@SteveKennedy (It's called Nirvana)

[confusingstraw]

@bvaughn My favorite component is definitely a tie between AutoSizer and VirtualScroll. They give me a ton of flexibility in how I want to go about presenting the data. My latest use case was rendering very large trees of data. First I flatten the tree, building indexes by traversing the visible children, then VirtualScroll provides me an index and I simply render the node. It's been a huge lifesaver.

[bvaughn]

Thanks @rgfoley! That's great to hear. :)

I wish browsers native provided element resize events so that components like AutoSizer were unnecessary...

I'd love to see your tree implementation if it's somewhere that can be shared. I started a branch of react-virtualized that adds a Tree component (that sounds very similar to the one you're describing) but haven't had the time yet to finish it. :D

[confusingstraw]

@bvaughn Which branch has the component? (unless it's just local)

Mine is somewhat tied to the structure that I'm working with, specifically it is for a file tree structure with permissions and such tied to each directory, and isn't currently public.

The data provided to the component is an Immutable.js Map where each node knows the keys for it's parent and it's children, and every node is at the highest level (there is no nesting). From there it is mostly implementation specific things.

I'd love to look at what you've made so far!

[kyle-ssg]

Hey virtualizers,

Came across this project last week and have really enjoyed implementing with it. As well as being great for performance it demonstrates an excellent use of higher order components.

I've developed the following since, all of which would have been useful (and perhaps will be) in some of our previous projects.

• A higher order component that behaves like input stepper but with the ability to manually highlight rows (e.g. via hovering a row), also stepping down from index 1 goes to index 2 rather than going to _rowStopIndex +1 (see https://github.com/bvaughn/react-virtualized/blob/master/source/ArrowKeyStepper/ArrowKeyStepper.js).
• A really simple higher order component to monitor focus within a container (e.g. clicking out and in of autocomplete input + results)
• An autocomplete component supporting search and highlighting
  
• A multiselect component, a similar setup to the autocomplete with the added ability to render / remove a select item
  
• A simplified infinite scroll supporting the ability to be reversed with a single prop
  

[bvaughn]

@rgfoley Haven't pushed it yet. Need to tidy it up more before doing so. When I find the time, I'll share. :)

Cool stuff, @kyle-ssg! Thanks for sharing. Does your async-infinite-scroll build on top of RV or is it a separate thing? (If it builds on top, I'd be interested in seeing your implementation.) :)

[oyeanuj]

@kyle-ssg looks great! any plans to open source these components or PR it back here? :)

[kyle-ssg]

@bvaughn The infinite scroll is just its own component with a combination of AutoResizer, InfiniteLoader and logic around setting scroll top and reloading based on a threshold prop. One of the motivations behind this was also to get the propType names a bit closer to the react native list view.

@oyeanuj Potentially yes - these have been built as part of a work project so I'd have to ok it first 😄 . Would need to decouple bits from a custom Input component I built but that wouldn't take long. I think open sourcing would be the more sensible option as they are indeed separate components (albeit very lightweight thanks to what RV provides).

[andrewmclagan]

We are using react virtualised in a new buildout fro EthicalJobs.com.au

Rendering lists of organisations and jobs around 40,000 to 100,000 at a time.

so so so sweeeeet!

[BTMPL]

1. I'm using react-virtualized in a data-grid displaying list of transaction made by the user
2. FlexTable, FlexColumn, WindowScroller
3. A PoC for banking institution

Only thing I'm missing over native implementation of rendering everything at one go is ability to search using Ctrl+F - I will have to implement that with a custom JS listener for the key combo and a override the browser implementation of search.

[bvaughn]

Thanks for the info @BTMPL!

You may want to check out my js-worker-search or redux-search libraries for the Ctrl+F filtering functionality. I use them in production in combination with react-virtualized and it works very smoothly.

[andrewmclagan]

We (EthicalJobs.com.au) are using it on our new build to display very large datasets within data-grid components. Performance was the main reason we migrated, although in the process we discovered allot to our likings. . . !

Thank you!

[amilajack]

I'm thinking of using it to display a list of around a hundred images. Does react-virtualized gc elements that are offscreen and have already been rendered?

[bvaughn]

@amilajack react-virtualized only caches elements temporarily while a user is scrolling. Otherwise they'll be GC'ed by the browser like normal. Others have used RV for a windowed gallery like you describe. :)

[JobLeonard]

We're building a data-browser for RNA data, where we have to quickly fetch and display data for a selection out of of 25000+ genes. The scrolling kinda breaks.. but we're basically using it more as a type-to-find input anyway:

A video shows off the use-case much better: https://youtu.be/l3FVAg1ZLH8

It's very much a WIP - as you can see the CSS is still very messed up (if you have any ideas what might be causing that please share, we're just naively importing the CSS + using react-bootstrap at the moment).

Above the react-select input you can actually see in the video how we did it before: a textarea where we had to type in the gene names, and then apply a regex afterwards... so yeah, big improvement there

[bvaughn]

Very cool @JobLeonard :)

The only thing I noticed messed up in the video was the placeholder text in react-select. (Is that what you meant?) Any chance you could point met at a demo? I'd be happy to take a look.

[jayryemure]

Hello, I'm using this great library in conjunction with React Select to create fancy drop downs with:

1. Search term filtering
2. Multiple selections
3. Custom options rendering
4. Dynamic option heights
5. Up to 100000 options

My stack is:

<ReactSelect.Async>
   <AutoSizer>
      <VirtualScroll>

As far as 4, I tried using CellMeasurer but my task required being able to skip thousands of rows so I measured it by hand using HTML Canvas Context which is quite a bit faster but not nearly as solid and accurate as what CellMeasurer does.

(I'd love to post a screenshot here because it looks so good, but corporate regulations and such)

[bvaughn]

Hey @jayryemure,

Thanks for the info! 😁 No worries on the screenshot. I understand.

Wondering if you've seen the react-select-fast-filter-options library yet for filtering react-select options? If you have so many options you would likely see further performance benefits from using that library. 😄

[andrewmclagan]

Currently writing a medium article on best practices for integration with a redux stack. Such a powerful combination.

[bvaughn]

Can't wait to read it! :)

On Aug 29, 2016 5:02 PM, "Andrew McLagan" [email protected] wrote:

Currently writing a medium article on best practices for integration with
a redux stack. Such a powerful combination.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bvaughn/react-virtualized/issues/147#issuecomment-243294343,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABzncKK1Io2oTY1E3L6cYmu2q_hvUlFks5qk3MqgaJpZM4HrE7D
.

[JobLeonard]

@bvaughn The website is currently broken for other reason (dirty use of globals and leaky state all over the place), once I got those issues figured out I'll get back to fixing the react-select component and share a demo page with you in private, ok? :)

[JobLeonard]

Wondering if you've seen the react-select-fast-filter-options library yet for filtering react-select options? If you have so many options you would likely see further performance benefits from using that library.

Thanks for that shout-out, btw! Some of our datasets have almost 30000 genes to filter through so we were choking on that for sure..

[jayryemure]

Wondering if you've seen the react-select-fast-filter-options library yet for filtering react-select options? If you have so many options you would likely see further performance benefits from using that library.

Yes, that was extremely helpful thank you. I'm indeed using js-search for fast filtering the 100,000 items and forgot to mention it. And now to actually answer your question:

1. What are you using react-virtualized for (eg. form controls, data grids, etc)?
   For now just managing custom drop down grids but I can totally seeing using this anywhere when displaying collections of data. (Just started a monster website and my first time using React).
2. Which component(s) do you find most useful?
   AutoSizer, VirtualScroll, CellMeasurer, InfiniteLoader. This list will probably increase as time goes on.
3. (Optional) What product(s) / project(s) are you using react-virtualized in?
   Developing our new MVP website. It's a beast of a website using an MVC back-end and a React (no flux, yet) front-end. No server-side React rendering. Talk is cheap but when it nears launching I'll be requesting sponsorship.

[bvaughn]

Sounds great @JobLeonard. I look forward to seeing it. 😁

And thanks for the follow-up info @jayryemure. Glad to hear that js-search and react-virtualized are working out well for you! Good luck on your MVP!

[JobLeonard]

BTW, before if I selected an item with a "multi"-enabled react-virtualized-select, the item would disappear from the list. After adding react-select-fast-filter-options this no longer happens. Is this a bug, or did I miss an option that I have to set when I provide a custom filter option?

[amertak]

Using the FlexTable for the visitors list on the website.
The number of visitors could be really huge so having a dynamic FlexTable is really useful.

[bvaughn]

@JobLeonard Was an oversight. Fixed in 0.0.5 (just released a moment ago).

[JobLeonard]

Just a heads-up, but it's still broken here, using these versions:

"react-select": "^0.9.1",
"react-select-fast-filter-options": "^0.0.5",
"react-virtualized-select": "^1.3.0",

(Not a big deal for us until we figure out all the other issues anyway)

[bvaughn]

@JobLeonard File an issue against react-select-fast-filter-options with repro case. I tested it earlier though, before I left my comment, and it seemed fine. However you're using an old version of react-select which might be the problem.

[renebrandel]

We are using react-virtualized to visualize the data browser in our GraphQL Backend-as-a-Service. Since www.graph.cool could potentially serve millions of data items we need a UI that can scale as well. The Grid, AutoSizer and InfiniteLoader is truly amazing and a perfect fit for our use case!

[ritz078]

Thanks @bvaughn for this awesome component.

We are using react-virtualised to render our infinite list of properties. There are some issues which I will be adding separately but it has been great for us so far.

You can see the video here. You can also see the FPS in video.

You can read the blog about the implementation on medium. We will be presenting the product in JsFoo this month.

[bvaughn]

Hey @ritz078. Great write up! Really enjoyed it. Shared it to Twitter. :smile:

Hope the presentation goes well. It looks like you've done great work on the site!

[ritz078]

Thanks. Glad you liked it. kudos to my whole team for pulling it off. 😄

[istarkov]

https://github.com/istarkov/revue github code review tool, published at revue.io

[bvaughn]

Looks slick @istarkov!!

[jedwards1211]

@bvaughn I'm using List in an IoT app to scroll through plots of historical data on numerous channels efficiently. Each plot uses a canvas. I subscribe/unsubscribe to data in a declarative fashion, meaning whatever props are mounted by List control what gets subscribed to. I just realized I want to make a PR to pass an isOverscan property to rowRenderer so that I can keep around DOM elements for overscan rows without actually subscribing to extra data or drawing anything to their canvasses.

[bvaughn]

Neat idea, @jedwards1211. I might name the property isVisible since I don't know how standard the "overscan" term really is. But I support the general idea!

[jedwards1211]

Right, I just thought since it's consistent with the overscanRows prop it would be clear what it means. isVisible seems kind of ambiguous to me, but maybe I'm thinking about it too hard.

[bvaughn]

Hm. I see your point. Guess I don't feel strongly about it either way. This would be more of an advanced property anyway.

[jedwards1211]

@bvaughn true. And you know, I fixed some other things and discovered I don't need it to get good performance in my app after all :P
On the other hand, I was thinking of rewriting a Tree component in my app to use react-virtualized...

[bvaughn]

Share it back here if you do. 😄 I have a branch with a virtualized tree that I haven't finished enough to release. And there's also fritz-c/react-sortable-tree. But in general, trees are cool and I would like to see more uses of virtualized trees.

[nhducit]

I'm trying to implement a comparison table like scroll sync example

[hmeerlo]

He just wanted to let you know what I'm building with react-virtualized. It is a planning tool showing workorders and planned personnel and machinery, with the sidebar showing availability for the chosen period. All scrollable parts (almost all views) are based on Grid or List. Keep up the good work on this project!

[bvaughn]

Whoa @hmeerlo! That looks freakin' cool! Thanks for sharing 😁

[sontek]

What are you using react-virtualized for (eg. form controls, data grids, etc)?
We are a conference registration and survey company. We are using react-virtualized for all our datatable needs:

• List of events
• List of attendees (sort, filter, add/remove columns, etc)
• Sortable / Movable questions on a survey

Which component(s) do you find most useful?
Grid, ScrollSync, and WindowScroller

We also use react-sortable-hoc with it.

[ArcanisCz]

We are now using react-virtualized for similar thing as @hmeerlo - for bus planning for bus travelling company. Contract is for potentially up to 600 buses to be listed on screen (=not paging) with all planned journeys for them. Having it all rendered with normal scrolling was huge strain for processor... (there are features as DnD you can imagine).
After using react-virtualized, everything became smooth again :)

At first, i wanted to try https://github.com/implausible/rickscroll but it seems they are doing things in very obscure way...

(Currently using only List and that AutoHeight thing, but can imagine usefulness of other components very well)

[tiberiumaxim]

Hi @bvaughn and thanks for your awesome work.

I am using it to display a long list (500-7000 text items) which consists of law elements: chapters, article titles, paragraphs, etc.

I am using WindowScroller, CellMeasurer and List in order to achieve this.
The only problem I have is using scrollToIndex. I found that it doesn't work with WindowScroller. Do you have any work around for this? I would like to create links inside the law content.

[bvaughn]

Hey @tiberiumaxim I don't actually use WindowScroller for anything outside of the react-virtualized demo site so it doesn't get as much attention. If you're using it, and willing to lend a hand, I'd be excited to get a PR from you adding support for scrollToIndex.

[tiberiumaxim]

Hi @bvaughn. I would also be delighted to contribute. Can you give me some guidance on how to approach this task? I barely know a thing about the module and I'm kinda new to React. How can we get in touch regarding this feature? I feel this is not the place to discuss this matter :) We could open a new issue for it.

[bvaughn]

See #540; it's all yours

[bunterWolf]

I use react-virtualized to speed up my electron file-manager. Which works great, thanks! ;)

But could not find any reference on how to add padding-top and padding-bottom to the list, which works with scrollTo.
Now I have a solution which works for me. Do you think this is a solid way for others too?

const PADDING_TOP = 50
const PADDING_BOTTOM = 50

<AutoSizer>
  {({ width, height }) => (
    <List
      height={(height - PADDING_TOP - PADDING_BOTTOM)}
      style={{
        // I overwrite the box-sizing to content-box to able to use the height without the padding
        boxSizing: 'content-box',
        // now we add padding and the file height of the list, will be the same as the Autosizer
        paddingTop: PADDING_TOP,
        paddingBottom: PADDING_BOTTOM
      }}

      // With position relative, the items position themselves at the innercontainer
      containerStyle={{position: 'relative'}} 
      ....
    />
)}
</AutoSizer>

Keyboard-Arrow navigation is made with scrollTo

[bvaughn]

Hey @bunterWolf! Thanks for sharing. That's a really cool solution, and a really neat looking widget! 😁 Love it!

[szahn]

Most free or commercial data grid components on the web aren't as fast as react virtualized, so I'm really grateful for this contribution. However, I did notice poor performance on older browsers (mostly IE, Firefox). SlickGrid actually outperformed MultiGrid in IE and Edge! Chrome always performs the best. There is still a need for good performance on legacy browsers and lower end CPUs, especially in the enterprise industry, and I find support for this lacking, although I understand how supporting both green and old browsers can be difficult due to time. This is why I feel we need a serious commercial data grid component built using modern concepts that can also support older browsers and out-perform all other libraries out there. For my scenario, I forked the virtual data grid and highly customized it. Added resizable, reorderable columns with search boxes to do column based searching, so had to build a forms-based component just for the grid headers. In addition, I also added alternating row colors and ability to select rows. Additional cell render templates were added for image cells.

I noticed that the grid component does not use css 3d transforms, is there a reason to not do this? I read it's faster to use transforms and positioning and utilizes the GPU. Wouldn't it also be faster to group cells into rows, therefore only transforming the y coordinate once per row? Grouping or caching cells by rows is also useful when having to do row selection which is something I needed. There are still performance issues when rendering 20+ columns and 5000+ rows on older browsers. I hope to see future improvements to this. Has anyone read this article (http://blog.atom.io/2015/06/24/rendering-improvements.html) and considering using quadrants/tiles instead of rows and cells to optmize rendering and caching?

[offsky]

At Toodledo.com we are using react-virtualized to display the user's to-do list, which could be as few as 0 items or as many as 20,000. We also have different row renderers based on the user's preferences, and screen size. Its really nice to be able to use the same list and just swap out the row renderer.

We have variable height rows that can grow upon user interaction, and the entire list is responsive as well, so we use <AutoSizer> and <CellMeasurer>. We also have a sticky header who's scroll needs to be synchronized with the List, so a lot is going on.

We needed a way to have consistent performance both with the initial load, and with the scrolling and react-virtualized does a nice job of both. Our rows are quite heavy at desktop size so we are struggling a bit the with unrendered rows coming into view on quick scrolling, but its manageable and better than what we have now. I am confident that we will be able to fine tune it before we release.

Thanks!

[taylorlee]

First of all, thanks for this library, it has been immensely useful!

What are you using react-virtualized for?

A simple spreadsheet editor for viewing / modifying data

Which component do you find most useful?

Grid! The HOCs are nice, but Grid is definitely the heavy lifter.

More context:

I needed to build a spreadsheet-like table with a header that was fixed vertically but not horizontally. None of the HOCs worked out of the box for me, because I needed:

1. vertical scrolling over thousands of rows
2. horizontal scrolling over tens of columns without altering column width (the rounded borders or the header and grid should scroll off the page, not slide into the grid-edge)
3. scroll synchronization between the header and the body
4. scrolling anywhere in the window triggers scrolling in the body
5. page resize should resize header and body
6. Arrow keys step through grid
7. other bells and whistles: sorting, searching, etc.

I tried combining many of the HOCs in various ways, (ScrollSync+WindowScroller+AutoSizer+ArrowKeyStepper+etc...) but it was relatively painful.

• 1 & 3 worked well with a ScrollSync and two Grids.
• For 2, I made the Grid render with full width to prevent virtual scrolling.
• For 4, I used the onWheel event on an outer element to proxy to the horizontal/vertical scroll handlers.
• For 5, I used forceUpdate combined with a standard resize handler like https://developer.mozilla.org/en-US/docs/Web/Events/resize#setTimeout
• For 6, I used document.activeElement + cartesian coordinates + Grid.scrollToCell (if cell not already in DOM)
• 7 was relatively straightforward with state-modifying actions.

Here is a snippet of roughly how I implemented 1-4:
https://gist.github.com/taylorlee/01954d237d61a3ec9b4a324f92a87291

Thanks again!

[oyeanuj]

@offsky I am very interested in your solution, especially since you have variable height rows that grow on user interaction, (and you use a sticky header) as well. I've had a really hard time making all that work with AutoSizer and CellMeasurer.

We have variable height rows that can grow upon user interaction, and the entire list is responsive as well, so we use and . We also have a sticky header who's scroll needs to be synchronized with the List, so a lot is going on.

Do you have a public link or gist for the same that you could share?

[jonikorpi]

At https://kausi.xyz/ I'm using <List> to infinite-scroll viewport-sized chunks of textareas. The implementation has some issues right now, but the app is live and usable. I previously used react-list, but switched to this library as it appears to be more mature and active, and I wanted to learn it for another project that I describe below.

Couple of the issues:

• Tabbing between textareas in some browsers can make a part of the page go off-screen, because of the _"Hey I see you focused on a form element that's not in the viewport. Let me scroll it into view for you."_ -thing some browsers do, even if overflow is supposed to be hidden.
• Scrolling performance is terrible in desktop Safari. (Haven't had time to check yet, but I may be accidentally triggering some re-renders while scrolling.)

I'm currently also developing a strategy game using <Grid>! I'm using it to create an infinitely scrollable hex grid: https://www.dropbox.com/s/e9tlhbmyvhbnm17/Screenshot%202017-04-29%2018.10.04.png?dl=0

Each grid cell renders a rectangular chunk of hexagons in the shape of a rhombus, which are then offset on the x-axis depending on the chunk's index to stitch the hexes together. Performance is great so far! I first tried using <Collection> to render hex-shaped chunks, but the initialization was way too slow, as the docs say.

[mking-clari]

We are using react-virtualized at my startup, Clari.

We use react-virtualized to implement data tables, messaging components, and option lists. For data tables, AutoSizer, ArrowKeyStepper, Grid, and ScrollSync are most useful. For messaging components, CellMeasurer is also useful because we have variable height messages. For option lists (normally based on results from a backend endpoint), List is most useful.

We do not use MultiGrid because we need a fixed footer in addition to a fixed header and fixed left column. It's straightforward to implement our custom multigrid using ScrollSync and Grid.

[MrNice]

At Waypoint Building, we use react-virtualized for interactive data tables and arbitrarily large lists. Our users can have tables with thousands of elements in them, but can quickly sort and filter the columns and rows. Our one list view which doesn't use react-virtualized loads extremely slowly.

We use Higher Order Components heavily to inject props into our cellRenderers so that we can build components by composing behaviors / styles. For example, there is a defaultStyle HOC which allows any cell type to have bold text when the column is selected and a blue background if the row is selected. This makes it pretty easy to consolidate behavior - a money HOC transforms numeric cellData into a pretty string, then an indicator HOC can color the text RED if it is negative, green if its positive. Finally, default styles are applied.

Doing this has kept a complicated codebase with many different kinds of data and data cells fairly easy to maintain and extend.

[bvaughn]

That's cool, @MrNice! Any chance you'd be able to share some of those HoCs (as a Gist or similar)? I understand if you can't, or don't have the time. Just seems like a useful thing to have as a reference for others.

[MrNice]

This is a WIP but shows our approach, based on the patterns from: Higher Order Components in Depth

export const CellRenderer = ({ cellData, ...rest }) => (
    <div title={cellData} {...rest} >
        {cellData}
    </div>
)

CellRenderer.propTypes = {
    cellData: React.PropTypes.any,
}

// NOTE: PP suffix indicates props proxy higher order component (HOC)
export function defaultStylePP(WrappedComponent) {
    class DefaultCellStyle extends React.Component {
        render() {
            const {style, selectedRow, selectedColumn, ...rest} = this.props
            const defaultStyle = {
                display: 'flex',
                alignItems: 'center',
                paddingLeft: '4px',
                fontSize: '16px',
                fontWeight: selectedColumn ? 600 : 'inherit',
                // FIXME (NICHOLAS): Choose the correct row background color
                backgroundColor: selectedRow ? '#239cb6' : 'inherit',
            }

            return <WrappedComponent style={assign({}, style, defaultStyle)} {...rest} />
        }
    }

    DefaultCellStyle.propTypes = {
        style: React.PropTypes.object,
        selectedRow: React.PropTypes.bool,
        selectedColumn: React.PropTypes.bool,
    }

    return DefaultCellStyle
}

export const DefaultCellRenderer = defaultStylePP(CellRenderer)

const moneyFormatter = d3.format('$,.2f')
export function moneyPP(WrappedComponent) {
    class MoneyCell extends React.Component {
        render() {
            const {cellData, ...rest} = this.props
            // NOTE: We must pass rest through instead of spreading props
            //       So that we don't overwrite the formatted cellData
            return <WrappedComponent cellData={moneyFormatter(cellData)} {...rest} />
        }
    }

    MoneyCell.propTypes = {
        style: React.PropTypes.object,
        cellData: React.PropTypes.any,
    }

    return MoneyCell
}

export const MoneyCellRenderer = compose(
    moneyPP,
    defaultStylePP
)(CellRenderer)

export function variancePP(WrappedComponent) {
    class VarianceCell extends React.Component {
        render() {
            const {cellData, selectedColumn, style, ...rest} = this.props

            const isNegative = isString(cellData) ?
                cellData.indexOf('-') === 0 :
                Number(cellData) < 0

            // TODO (Nicholas): Can d3 do this formatting for us?
            const prefix = isNegative ? '' : '+'

            // FIXME (NICHOLAS): Choose correct variance colors
            const color = isNegative ? '#F00' : '#0F0'
            const proxiedStyle = selectedColumn ? Object.assign({}, style, { color }) : style

            // NOTE: We must explicitly pass through selectedColumn
            //       To avoid the props spread operation
            //       which would overwrite our style and cellData changes
            return (
                <WrappedComponent style={proxiedStyle}
                    cellData={`${prefix}${cellData}`}
                    selectedColumn={selectedColumn}
                    {...rest}
                />
            )
            //      (We pull selectedColumn out of props to make
            //       integration points obvious, else we could use
            //       this.props.selectedColumn AND {...rest})
        }
    }

    VarianceCell.propTypes = {
        style: React.PropTypes.object,
        cellData: React.PropTypes.any,
        selectedColumn: React.PropTypes.bool,
    }

    return VarianceCell
}

// NOTE: Variance Must run AFTER Money
//       Remember compose applies right to left
//       But the renders happen left to right
//       (And I might have gotten these things confused)
export const VarianceCellRenderer = compose(
    moneyPP,
    variancePP,
    defaultStylePP
)(CellRenderer)

@bvaughn Would you prefer this in a gist, or can it stay in this sticky thread?

[chenlanlan]

@bvaughn
Have been using react-virtualized in a UI project to render large data set in a data table.
Many modules/functionalities in data tables are very useful, like Scroll, Selection, Sort...

For one thing, I want to ask you for suggestion. Since react-virtualized is using DOM recycling, only contents visible are going into DOM. Do you have any suggestion for supporting somthing like Ctrl+F search in data tables.
I saw your reply to @BTMPL, I wonder if that is similar as using redux-search in data tables?

Thanks!

[bvaughn]

Native browser search is not supported by any windowing library
unfortunately. You can use a custom solution, like
js-worker-search/js-search/redux-search. That's the best solution I'm aware
of at the moment.

On Aug 9, 2017 11:52 AM, "Sally Chen" [e-mail] wrote:

@bvaughn https://github.com/bvaughn
Have been using react-virtualized in a UI project to render large data set
in a data table.
Many modules/functionalities in data tables are very useful, like Scroll,
Selection, Sort...

For one thing, I want to ask you for suggestion. Since react-virtualized
is using DOM recycling, only contents visible are going into DOM. Do you
have any suggestion for supporting somthing like Ctrl+F search in data
tables.
I saw your reply to @BTMPL https://github.com/btmpl, I wonder if that
is similar as using redux-search in data tables?

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bvaughn/react-virtualized/issues/147#issuecomment-321348118,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABznSlSV5_aT8elxsizVkkYbzag_Nscks5sWgAGgaJpZM4HrE7D
.

[dingchaoyan1983]

MultiGrid that can fixedRightColumn and fixedLeftColumn
you can check the source code from here

[turnerniles]

@bvaughn
We built a pivot component based on react-virtualized, react-virtualized-pivot.

[bvaughn]

Oh that's cool! Thanks for sharing :)

[xiaodaigh]

I am using virtualize to show a long list of credit card transactions. So I am happy for it to be fixed width but want the height to vary. Also to make it responsive

[Codelica]

I'm using AutoSizer, List and my own cache based on how CellMeasurerCache works (thanks for the tips on Slack :) )

My use is for a realtime app that evaluates incoming API calls providing stats and logs (the List component) for dev/troubleshooting. This project was a godsend for the logs. Thanks again...

[bvaughn]

That looks very cool @Codelica 😄 Thanks for sharing!

Don't suppose you could share any of your custom cache code? 😄

[Codelica]

To be honest, after several variations (some using / managing my own CellMeasurerCache), where I ended up is almost embarrassingly simple. I sort of sole two ideas used by CellMeasuer (keyMapper and cache.rowHeight).

Basically every row that comes in (via websocket) has a unique ID, so I calculate heights and store that info in a Map as they come in (and remove rolled ones). Then I feed the List a getRowHeight function that pulls directly from the Map via the rows ID (rather than index). And bumped up my max log size before rolling so that I wouldn't have to recomputeRowHeights() until people are being real gluttons. ;) So a little compromise, but seems to work well.

[bvaughn]

Thanks for elaborating!

so I calculate heights and store that info in a Map as they come in

I'm mostly interested in how you do the calculations in a way that makes it faster than using CellMeasurer 😄 Anything I could learn from to improve the default behavior?

[Codelica]

Ahhh... I see. Well to be honest I'm not sure it would be any "quicker" mechanics-wise for lookups. (Map vs plucking from an object in the end?). I imagine CellMeasurer has some additional overhead in what it does calculating the heights, but in the end the reason I didn't use it wasn't directly related the performance of cached height lookups themselves. It was more about viewing performance when scrolling back (up).

Basically lots of log rows can come in quickly (hundreds a second at times) and it's trivial for me to compute their height as they come in so I always have a complete cache of all that info before any element is rendered in the list. So scrolling back up is always smooth, no jerkyness due to calculations of height data not in the cache yet (which would come going the CellMeasurer route in my case)

The only real hitch for me at this point is once the log starts to roll (at 100k entries currently) where recomputeRowHeights() has to hit, potentially quite frequently as new data pours in. There are things I can do about that (delaying the recalc until they decide to scroll up again, or maybe the flow has slowed or stopped a cycle).

But beyond that for my use case RV would need to have more control over and understanding of the manipulation of the list/grid data. Like telling it index 0-121 are gone now and it having an optimal way of just removing that range and recalculating, etc. I can't say I looked deep enough to understand or know what's going on completely, but it seemed like that would be a somewhat difficult given they way the internal caches are currently (object props based on index numbers IIRC).

Sorry if I'm not clear here. But basically just saying it would need to be able to better "understand" list modifications for my use case rather then a full recomputeRowHeights() with 10 new rows rolling through. (even though cached heights are at least used) The next step would just for that recompute to be minimized to only what's changed. But in order to do that it would have to have an understanding of the change and the underlying caches would have to be in some form that make manipulation like that possible/performant.

Wow.. that's some rambling. Time to cut myself off ;)

EDIT: Actually and now that I think about how row height have to be formulated and summed, it may not even be possible (or worthwhile) ! It's a tough problem for sure.

[bvaughn]

Ahhh... I see. Well to be honest I'm not sure it would be any "quicker" mechanics-wise for lookups. (Map vs plucking from an object in the end?). I imagine CellMeasurer has some additional overhead in what it does calculating the heights, but in the end the reason I didn't use it wasn't directly related the performance of cached height lookups themselves. It was more about viewing performance when scrolling back (up).

Ah, yes. Sounds like we're both using objects for our "maps". I wouldn't imagine much of a perf difference there. I was more asking about the process of measuring/calculating initially.

Basically lots of log rows can come in quickly (hundreds a second at times) and it's trivial for me to compute their height as they come in so I always have a complete cache of all that info before any element is rendered in the list. So scrolling back up is always smooth, no jerkyness due to calculations of height data not in the cache yet (which would come going the CellMeasurer route in my case)

Hm! This should be the case for CellMeasurer as well, because once an item has been measured, its measurements should come from the CellMeasurerCache and CellMeasurer should not measure it again.

But beyond that for my use case RV would need to have more control over and understanding of the manipulation of the list/grid data. Like telling it index 0-121 are gone now and it having an optimal way of just removing that range and recalculating, etc. I can't say I looked deep enough to understand or know what's going on completely, but it seemed like that would be a somewhat difficult given they way the internal caches are currently (object props based on index numbers IIRC).

Based on the index by default, but can be based on a more stable id if you provide the cache a keyMapper prop.

Sorry if I'm not clear here. But basically just saying it would need to be able to better "understand" list modifications for my use case rather then a full recomputeRowHeights() with 10 new rows rolling through. (even though cached heights are at least used) The next step would just for that recompute to be minimized to only what's changed. But in order to do that it would have to have an understanding of the change and the underlying caches would have to be in some form that make manipulation like that possible/performant.

I may be misunderstanding you, but this is part of why the measurements (CellMeasurerCache) are stored separately from positions (List/Grid internal cache).

All that being said, I believe that you found a way to improve perf in your app. I'd love to better understand how you did it though, in case anything could be applied to the built-in react-virtualized components. :smile: Don't suppose you could show me your code?

[JobLeonard]

So the application I've been working on is finally opened to the public:

https://github.com/linnarsson-lab/loom-viewer

I probably should start adding some gifs...

To quote my comment from last year:

We're building a data-browser for RNA data, where we have to quickly fetch and display data for a selection out of of 25000+ genes. The scrolling kinda breaks.. but we're basically using it more as a type-to-find input anyway

Funny enough, the scrolling (with the mouse) is currently broken too, but in this case it's a known issue with React-Select, not me ;)

[Codelica]

Hm! This should be the case for CellMeasurer as well, because once an item has been measured, its measurements should come from the CellMeasurerCache and CellMeasurer should not measure it again.

Yep, that part is true, but isn't really the snag I ran into using it. :) The key to what I was trying to avoid with it is actually mentioned -- "once the item has been measured". Basically at times my new log data can come in so quickly that many items are not rendered as they come in, and therefore are not measured (and height cached) by CellMeasurer as they come in.

For example, my list view may show 10-30 items at a time (depending on heights), and is usually pinned to the "end" of the list via scrollToIndex (although users can override that by moving away from the end). So if 400 new log entries hit during a render cycle, the majority wouldn't get measured and cached by CellMeasurer (unless I would have cranked overscanRowCount sky high perhaps? although that feels like a bad idea. :) )

The end effect of going that deferred measurement route, with chunks of missing heights in the CellMeasurer cache, was jerky upward scroll movement, as CellMeasurer would actually measure and cache heights that it didn't have a chance to previously. Basically it's what some people are trying to find a _general_ solution for in #803 and #610.

Since I had an easy calculation I could run to generate and cache row heights for each item, as they came in, before each render, that just seemed to be the cleanest route. At first I did try using CellMeasurerCache myself to manually manage the height data (via set() and clear()), but once I looked at what its rowHeight() function was doing, I just decided to do my own map. Also to be insulated from any changes that may come to CellMeasurerCache.

Based on the index by default, but can be based on a more stable id if you provide the cache a keyMapper prop.

Yes.. and that's a concept I stole from CellMeasurer for my cache and measure functions also. Definitely needed in my case.

I think where I probably confused you is talking about several caches without being specific. Both CellMeasurerCache's height cache (when used with a keyMapper) and my simple height cache serve the same function -- caching raw height info for each row via some id. I just cached things manually so I was assured there was complete height cache, with entry for every row as mentioned above. I doubt there is much (if any) performance benefit beyond working around that scrolling quirk. If there was any, it would just be from reduced code for a height "measurement" as mine is trivial.

But then there are the other "higher level" internal caches for the list (_cellCache and _styleCache) which are used, and get constructed from the raw cached height data, and if I understand correctly, are cleared and rebuilt when a recomputeRowHeights() hits. While I understand that should be "quick" using cached measurements, when there are potentially 100k rows in my list, it's not trivial to do that a lot with new data streaming in. Since I'm just clearing entries off the top of the list and tacking some on the end each cycle, I'd _like to think_ there is a better way than dumping those completely. However given how the heights are cumulatively summed, that's probably just reality. Any optimization there would probably have to come on my end, only calling recomputeRowHeights() when really needed, rather than every render cycle once the log starts to roll.

All that being said, I believe that you found a way to improve perf in your app. I'd love to better understand how you did it though, in case anything could be applied to the built-in react-virtualized components. 😄 Don't suppose you could show me your code?

Prepare for disappointment!! ;) The relevant parts are really trivial...

Basically I get new rows via via websocket in a parent container component. As they come in, I just call the appropriate method to calculate and cache height which are like:

// Set our calculated height for a PostAuth log row
setPostAuthRowHeight(row) {
  this.rowHeightCache.set(row.id, (20 + 20 * row.payload.extraRows));
}

...and of course delete id's from that rowHeighCache Map once they are pushed out of the log. So I always have fully populated cache for the log(s) based on ID. Then for my list:

<List
  style={{outline: 'none' }}
  width={width}
  height={height}
  rowCount={p.log.length}
  noRowsRenderer={this.noRowsRenderer.bind(this)}
  rowRenderer={this.rowRenderer.bind(this)}
  onScroll={this.logScrolled.bind(this)}
  scrollToIndex= {p.syncLog ? p.log.length -1 : undefined }
  rowHeight={this.getRowHeight.bind(this)}
  ref={p.sendListElement}
/>

Which gets the heights via getRowHeight() which is:

// Return our calculated hight for a log row
getRowHeight({index}) {
  return this.props.getRowHeight(this.props.log[index].id);
}

Which just uses the getRowHeight function prop that's passed in:

// Get our calculated height for a log row (sent as prop to WebConsole)
getRowHeight(id) {
  return this.rowHeightCache.get(id);
}

I'm sure you get the idea. Its just a raw Map being used. Sorry to give you any false hope. :)

Although now that I think about it, I may just try sending the calculated row hight in as part of the actual log entry. That should be about as direct as possible!

Sorry to get wordy, thanks again.

[treyhoover]

I put together a little slider/carousel with react-virtualized and react-motion.

Feedback/PRs welcome! 🙂 https://github.com/treyhoover/react-sliderp

[kvolkovich-sc]

Hi! We builds filemanager for react using react-virtualized.

https://github.com/OpusCapita/filemanager

Now we use Table for files ListView, but in near future we'll implement GridView and TreeView using your awesome library. :smiley:

[bvaughn]

Cool! Thanks for sharing, @kvolkovich-sc 😁

[ryanflowers]

Hi there! Is anyone using react-virtualized with the cellMeasurer to renderer a List having truely dynamic row heights they can share? I mean row content is variable which is of unknown height and cannot be provided to the RV component. I see references to doing this in other issues but not seeing it actually being done in any examples. From what I can see the height is always provided in the examples. I am building a chat client which each message has content of variable height. I assume this is what the cellMeasurer is built for. In my case my measurerCache gets updated according to row content height so the measurer seems to be doing its job but the Grid ref is always undefined.

/Grid.js
if (this.Grid) {
this.Grid.invalidateCellSizeAfterRender({

Any examples of someone actually having RV calculate the height of the content would be a great help!

[bvaughn]

Hi @ryanflowers. This issue isn't for Q&A. 😄 That's better suited for Slack and Stack Overflow.

There's an example of what you're asking about on the react-virtualized demo page and the source is in this repo as well. If you have follow-up questions about this, please hop in the Slack and ask them there. 👍

[Taylord93]

I am using this for a Cordova app I am building which lists out about 700+ objects in the form of component links that are pretty complex, lots of even handlers and dynamic data. I came across it while searching for a solution because when the whole list is rendered, the animations and transitions on the page broke down quite a bit and became unusable. That being said, WindowScroller and VirtualScroll are the only components I have used so far. Its been great! The app itself is basically a creature repository for D&D that is filterable/searchable, but there is a LOT of data processing, and react-virtualized has made my performance skyrocket.

Really the only issue I've come across is making a mobile 1 column grid responsive to become a 2 column grid on larger screen sizes.

[cquiroz]

I've created a partial Scala.js facade react-virtualized. For the moment just Table as that is the one I need but I may expand to cover the rest as needed. The facade is here

https://github.com/cquiroz/scalajs-react-virtualized

We use it on a realtime monitoring software on the Gemini Observatory where our primary language is scala and use scala.js for the front end

Thanks this project has been invaluable to make our UI much more usable

[queicherius]

What are you using react-virtualized for (eg. form controls, data grids, etc)?

• Large tables and grids with up to 5.000 entries. Before using it, filtering the tables were painfully slow (up to 10 seconds) and scrolling was stuttering. Now everything is filtered in the <10ms area.
• Large select menus with up to 100.000 entries via react-select-virtualized

Which component(s) do you find most useful?

Table / Column, WindowScroller, AutoSizer, List

(Optional) What product(s) / project(s) are you using react-virtualized in?

gw2efficiency for the virtualized tables (these are all the skins in the game Guild Wars 2, ordered by how many uses of the page have unlocked them and their unlock value).

Also, multiple internal projects (that I can sadly not share) use the select menus.

[MarcMagnin]

@Codelica great interface! BTW how do you deal with window resize? Do you recalculate all rows height?
I like the font you've been using their! May I ask what is that font?

[Codelica]

@MarcMagnin Thx. Mobile (phone) support wasn't a concern for this one, so there is a reasonable min-width set to keep log lines from wrapping, and a fixed hight is set for the console view. But yes, changes like that would require a re-calc/render.

I used React Material UI on that (https://material-ui-next.com/) so the main layout font is Roboto. Console view uses Source Code Pro.

[evanfrawley]

What are you using react-virtualized for (eg. form controls, data grids, etc)?

• I used it to make an emoji picker & meme picker for a side project!
• It was for a data grid of sorts
  
  Which component(s) do you find most useful?
• VirtualGrid!
  (Optional) What product(s) / project(s) are you using react-virtualized in?
  See above. I'll also dabble with the library in future side projects

[andrewvmail]

Using it in a mobile cordova app for chat.

[partha360]

Great work @bvaughn...thank you so much for your contribution...

Here is my Reference implementation,

List of popular movies from tmpb (over 18000 of them). Used flex-box, material-ui to display as cards.

Demo
Source
React-Virualized reference (InfiniteLoaded + WindowsScroller + AutoSizer + List)

<InfiniteLoader
              isRowLoaded={this.isRowLoaded}
              loadMoreRows={this.loadMoreRows}
              rowCount={
                this.props.page.page === this.props.page.totalPages
                  ? this.props.movies.length + 1
                  : this.props.movies.length
              }
              minimumBatchSize={5}
            >
              {({ onRowsRendered, registerChild }) => (
                <WindowScroller>
                  {({ height, isScrolling, scrollTop }) => (
                    <AutoSizer disableHeight>
                      {({ width }) => {
                        itemsPerRow = Math.floor(width / 415);
                        const rowCount = Math.ceil(this.props.movies.length / itemsPerRow);
                        return (
                          <List
                            ref={registerChild}
                            onRowsRendered={onRowsRendered}
                            isScrolling={isScrolling}
                            autoHeight
                            width={width}
                            height={height}
                            rowCount={rowCount}
                            rowHeight={820}
                            rowRenderer={this.rowRenderer}
                            scrollTop={scrollTop}
                          />
                        );
                      }}
                  </AutoSizer>
              )}
            </WindowScroller>
        )}
 </InfiniteLoader>

[AndreyChernykh]

@turnerniles Hi! How did you manage to make the sync scroll for the header and left column so smooth? I've looked at your code, but I see just a <ScrollSync> in use. Using the same component I still have a visible lag between scroll position of the main table and the header. And it is a known issue https://github.com/bvaughn/react-virtualized/issues/369

So, I would be great if you explain the solution briefly.

Thank you!

[reyanshmishra]

@bvaughn thank you for creating such an awesome project. I had a question I don't know if this is the right place to ask? Can I use error boundaries for an item in a list?

[WhoAteDaCake]

1. Using a tool built on top of it https://github.com/SpotlightData/react-lazylog to be able to load massive text files without breaking the page
2. VirtualList
3. Nanowire (https://www.spotlightdata.co.uk/)

[javidjamae]

Thanks for all the great work you've done on this project! We use it for all of our grids on www.skipcard.com

[Carrotzpc]

Hi there, thanks a lot. I use react-virtualized to display massive logs on tenxcloud.com. But I have recently encountered a problem, I can only copy the log of the current page, but I can't copy the log across pages. I didn't find the relevant content in the official documentation. Does anyone know how to solve this problem?

PS: The problem can be reproduced on this page https://bvaughn.github.io/react-virtualized/#/components/List