rfc: virtualizing stack prototype

[scomea]

💬 RFC

We're planning on supporting virtualization in FAST components to enable authors to create zippy ui experiences that display large data sets. Think grids with thousands of rows of data or very large tree views.

I've been prototyping a "virtualizing-stack" concept at the branch below and am adding this thread as a place for related discussion. Note this is a prototype branch so stuff may be in a very rough state and buggy.

The approach being taken here is to enable fast components that use templating to render large datasets where each item has a uniform height/width to render only items that are in a particular 'viewport' in the ui. Out of view items are not added to the DOM but space is reserved for them.

A mechanism to support variable sized items where authors are able to provide a method of (quickly) calculating item sizes would also be added.

https://github.com/microsoft/fast/tree/users/scomea/virt-stack-panel

The branch currently has:

• a new 'virtualizing-stack' component and base class.
• modified data grid derived from 'virtualizing-stack-base' with a 100k row sample.

[scomea]

Wired up keyboarding in the data grid component including navigating to rows that are virtualized.

[scomea]

Broke out a PR for the "virtual-list" component on this branch - #5529.

I'm continuing to work on the prototype branch to refine the data grid integration as well as having added a new "loader-card" concept.

I took the "layout update delay" out of the list component itself in favor of letting the item templates handle any desired loading management directly. The idea behind a loader card is that it has a "delay-load" slot which is only rendered after a timer elapses, this could allow authors to prevent kicking off complex card rendering for something that just flies by on a big scroll.

Also, the card has a "stagger-loading" functionality which allows multiple instances of these cards to coordinate a staggered load order so only one loads up its "delay-load" slot over a specified interval. The idea here is to not overwhelm a frame with rendering a bunch of new cards all at once to avoid dropping frames.

[jattasNI]

I'm super excited to see the FAST data grid maturing like this!

One performance optimization I've seen other UI frameworks use is to avoid instantiating new instances of the template on scroll by re-using the same elements for different rows. The client typically implements a callback function that is given a reference to the re-used element and is responsible for reconfiguring its contents before it gets rendered on screen. One example is the iOS UIKit UITableView but I think I've seen it in HTML grids too.

Is this something that this architecture supports or could support?

[rajsite]

I've also been interested in a virtualized table component to participate in a FAST based design system and I came across <regular-table> which is used as a dependency to implement tables for the perspective framework.

The examples show the data model of <regular-table> scrolling through 2 billion rows very smoothly. And the canvas example where a flyover renders pixels of an image region as cells of a table is just showing off :P

Thought it could be an interesting reference for api decisions (like configuring virtualized scrolling on each axis) or the async data model.

Edit: Moved comment here from: #5529 (comment)

[scomea]

One performance optimization I've seen other UI frameworks use is to avoid instantiating new instances of the template on scroll by re-using the same elements for different rows. The client typically implements a callback function that is given a reference to the re-used element and is responsible for reconfiguring its contents before it gets rendered on screen. One example is the iOS UIKit UITableView but I think I've seen it in HTML grids too.

Is this something that this architecture supports or could support?

I think so. I'm working on ideas along those lines in the prototype branch, although my first crack at it may be a bit different and push the element reuse down to the list item level with the idea of having super-light fast loading list elements that can manage loading/caching/reusing their more complex internals. Would be more flexible to let authors optimize on their own element templates IMO. Haven't gotten this running yet, but I think it can work.

[scomea]

The examples show the data model of <regular-table> scrolling through 2 billion rows very smoothly.

The first iteration of virtual list actually reserves space for all the elements (ie. the container element is tall/wide enough to hold all the elements if they were to be rendered). This breaks down with huge collections as browsers don't necessarily handle very large elements well, for example native scroll bars start balking when they are scrolling something x-million pixels across. Being able to work with native scroll bars is useful so I think it makes sense as a starting point, but to get to huge collections we'd likely have to do some custom scrolling container implementation.

[scomea]

Added a rough "gallery panel" component to the prototype branch as a test case for virtualizing variable height virtual lists.

The top gallery group is a list of gallery groups each containing a variable number of galleries of images. So, three levels of virtualizing containers.