React Virtualized components currently assume that cells will be laid out in a checkerboard pattern. This doesn't support layouts like the Pinterest-style columns. It would be nice to support those layouts (in a backwards compatible way). It probably touches on a few areas:
The GridUtils initCellMetadata method currently determines the positioning of cells. It assumes that cells in both horizontal and vertical axis are laid out in a straight line.
This positioning logic could be overridden by allowing users to supply a custom function that calculates cell metadata. Alternately, optional columnOffset and rowOffset callback functions could be added and passed to the existing initCellMetadata to determine the metadata.
This change would increase the amount of time require to compute metadata from X+Y (where X is the number of columns and Y is the number of rows) to X*Y so it should be an opt-in setting, not always on. (We don't want to slow down existing users who don't require this functionality.)
This performance impact could perhaps be minimized by only calculating the size/offset of cells up until the current window of data and just using an initial estimated size to determine the scrollable boundaries of the grid (but this would need to be tested to see if it worked well, it's just an idea).
The GridUtils getVisibleCellIndices method currently determines the range of columns and rows to render. This method assumes evenly distributed data (a checkerboard pattern) and so it takes the short-cut of calculating only the start/stop indices for each axis.
In order to support a more fluid layout, this method would probably need to drop the concept of x/y axes entirely and return a set of axis-agnostic cell indices to be rendered.
VirtualScroll and FlexTable components are both just HOCs that decorate a Grid for convenience. The change mentioned above (switching from column and row indices to a cell index) may suggest the need for a new type of component that's more layout-agnostic (Window?). Perhaps the Grid component could then be refactored to just be a HOC that uses this component in order to support backwards compatible use cases.
Have an initial working prototype of this in a branch. Need to clean it up some more and decide how much code I want to share between Grid and Collection. Grid can make some shortcut assumptions about layouts since it's cells are always in a checkerboard arrangement. Collection, on the other hand, cannot.
Also not sure about the name Collection. It's kind of vague. Any better suggestions?

FYI @oyeanuj, @olivierandriessen, kasrak ~ Progress!
Most helpful comment
Have an initial working prototype of this in a branch. Need to clean it up some more and decide how much code I want to share between
GridandCollection.Gridcan make some shortcut assumptions about layouts since it's cells are always in a checkerboard arrangement.Collection, on the other hand, cannot.Also not sure about the name
Collection. It's kind of vague. Any better suggestions?FYI @oyeanuj, @olivierandriessen, kasrak ~ Progress!