[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 k@airtable.com!

[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. :)