React-virtualized: Optimization Idea: DOM recycling

[amilajack]

Wasted a bunch of time on twitter and I found these:

https://twitter.com/paul_irish/status/755107282917076992
https://developers.google.com/web/updates/2016/07/infinite-scroller

Could be a pretty significant performance improvement, especially on low-end devices.

[bvaughn]

Hey thanks for taking the time to share. 😄 This blog post looks like it's basically describing the technique that react-virtualized is already doing, with one exception: I am not currently recycling nodes (swapping from the top to the bottom). An earlier version of react-virtualized did this but my performance tests indicated that, within React's ecosystem at least, it was faster to do what I'm now doing (eg throwing away the top node and creating a new bottom node).

But it is something I check every now and again to see if I get different results. In fact I have a branch open, locally, where I was checking a few things like that again just yesterday. 😁

I'm going to close this issue since it's not super actionable but I appreciate the pointer to the info. If you get around to doing any prototyping yourself, feel free to share your results with me here though- (I'll still get notifications of comments)- or even as a PR. Collaboration is welcome.

[bvaughn]

I should add that one more thing that react-virtualized does that makes this trickier to deal with than the example test harness Irish links to is that I allow users to programmatically jump to a specific row or column using its index. This requires me to process/measure all rows _before_ (above/left) the one being jumped to.

For example, try scrolling to the bottom of his demo list (using either a mouse wheel or a track pad). It will take you about 60 seconds to eventually get there. In react-virtualized you can jump to it directly using scrollbar or keyboard shortcuts. This is due to what I mention above. ^

[amilajack]

Oh wow, I never knew that react-virtualized implemented it that way before. Is there some documentation describing how react-virtualized works?

[bvaughn]

Hm, not really. I guess I've targeted my docs at people wanting to _use_ react-virtualized more so than at people wanting to re-implement a similar library.

Essentially react-virtualized works like this (to borrow his screenshot):

But react-virtualized works in both directions (vertical and horizontal) _and_ it allows_ you to jump to a specific row/column using props. (Let's say a user has a 100,000 x 100,000 grid and they're searching for a specific cell- you can tell react-virtualized to show column 300, row 1,000 and it will jump to ensure that that specific cell is visible and rendered. That behavior was the main reason I created react-virtualized in the first place (instead of using Facebook's fixed-data-table) but it also makes certain things a little trickier. 😁

[bvaughn]

The link you shared is still great though. I'm reading through it now to see if there are any little things I can pick up. Irish is fantastic so I can always learn stuff from him.

[amilajack]

I think it would be a good idea to show a side-by-side comparison between the performance differences and memory usage of each library. What do you think?

[bvaughn]

"of each library" ?

Are you suggesting comparing react-virtualized to Irish's library?

That's too apples and oranges. RV is built on top of React for one and so the virtual DOM and other things come into play. It also supports a lot more configurable options than the library that was linked to. I don't think a side-by-side comparison would be that meaningful.

[amilajack]

How about comparing it against fixed-data-table?

[bvaughn]

If you'd like to create a side-by-side comparison, go for it. 😄 Might be nice for folks wanting to compare the 2 libraries.

react-virtualized does a lot more than fixed-data-table too. Much bigger Api. Windows horizontally and vertically. Allows scrolling to cells by props. Etc.

[aputinski]

I am not currently recycling nodes (swapping from the top to the bottom). An earlier version of react-virtualized

In that version, are you saying that each cell just received componentWillReceiveProps with new props? My current cell is fairly expensive on initial render, but subsequent renders are pretty performant. I was hoping there would be a way to avoid mounting a fresh component each time, but looking through the code, it seems like this would be non-trivial?

[bvaughn]

Hey @aputinski,

In that version, are you saying that each cell just received componentWillReceiveProps with new props?

It's not clear to me what you're referring to. You may be referring to React elements (JavaScript objects with lifecycle hooks like componentWillReceiveProps). If that's the case, I'm curious why your componentDidMount (or the initial call to render) is "expensive"?

I was referring to DOM elements above. React decides whether to reuse or recreate DOM elements based on their type (eg div) and key (which for react-virtualized is just the index of the item within the larger collection). I haven't found it to be worthwhile to try to recycle DOM elements (by rotating keys) and so I don't do it. You _could_ experiment with this- by ignoring the key I pass you.

[aputinski]

Sorry, I was referring to the React element, not the underlying DOM node. My cell has some nested components that are React.PureComponents, so if the cell were to just receive new props, React would things accordingly and the pure components wouldn't get re-rendered, but as it is now, each time a cell scrolls into view, the entire thing has to get re-mounted.

[aputinski]

I'll play around with the keys idea and see what happens. Thanks for all your work on this library — really awesome.

[Matchlighter]

@aputinski Did you ever do anything in the way of recycling keys? I'm in a very similar place where my rows are relatively complex, but are optimized with PureComponents.