domenic / infinite-list-study-group

Moved to WICG/virtual-scroller

Moved

This repository has consolidated into the WICG/virtual-scroller repository, in particular the study-group subdirectory.

infinite-list-study-group's Issues

The _code editor_ use case

(Opening this to join the discussion—I unfortunately found out about this work only now, via the Chrome Dev Summit.)

So, another type of software that has been implementing something like this is code editors. All of CodeMirror (which I maintain), Ace, and Monaco do some kind of virtual rendering, where in order to support huge documents without bringing the browser to its knees, they only render the lines of code around the viewport.

This is different from classical infinite scrolling in that the content isn't open-ended—there's a clear start and end to it, and the vertical scrollbar should provide a reasonable approximation of the height of the entire document right away. But other than that, I think there's a lot of overlap. We've also been having problems getting browser search to work (or, more accurately, have just given up on that for the time being, falling back to custom search interfaces, which is problematic for various reasons).

One thing that concerns me about the direction that uses hidden DOM nodes is that creating those DOM nodes might already be too expensive. In CodeMirror, we strive to support any document size that reasonable fits in memory, trying to keep our memory consumption for non-visible parts of the document under 2x the size of the strings needed to represent the document text. In this context, given the memory consumed by browsers' DOM implementations, creating the entire DOM structure for the document might just not be viable for memory pressure reasons.

As such, when I heard about this work I was initially hoping that it'd include some programmatic way for JavaScript code to react to search events. That'd be a much less convenient API to plug in to, but for a library like this, knowing in advance what the user is searching for would allow the library to selectively render those parts of the DOM that match the search string, at which point the browser's native code could 'see' them and scroll them into view as appropriate. (There'd be corner cases like searches that match too many lines that we could still not handle perfectly, but the user experience would still go from awful to pretty good, which'd be a big win.)

One thing that's not quite clear to me yet is how you're addressing 'flickering' during quick scrolling, where empty space becomes visible as you scroll quickly because scroll events are delivered only after the scrolling took place. Will these components be able to hook into the browser's native scroll behavior in a way that allows them to render or un-hide their content before it becomes visible, or will they have to fake their own scrolling? (The latter is problematic because you'll never exactly duplicate the native behavior or performance.)

clusterize.js

I just saw Gray Norton's talk from the Chrome conference a few days ago.

I wanted to point out clusterize.js. It is a framework-less script that I've had a lot of great luck with in the past week. It was amazingly easy to adopt and makes similar design decisions as <virtual-scroller>. That's it, thought you'd be interested.

Consider including react-window

The latest infinite scrolling library from the React team appears to be highly performant, with including in this study

https://react-window.now.sh/

maybe this can help too

maybe this can give you some creative ideas? this is an infinite scrolling tile grid that i have been working on for web based apps. tile grids can be a great choice depending on your use case.

https://github.com/arxii/preact-grid
https://arxii.github.io/preact-grid/

Bible: Long but not infinite list

I have a use case that is a bit different but may be interesting for your research group in terms of requirements.

I have Bible search engine that uses an in memory Bible. It searches onKeyDown and results appear immediately. The regex search is very fast but the DOM renders slowly and so is broken up by timers.

https://omysoul.github.io/omysoul/react-bible/
https://github.com/philholden/react-bible

I would have liked to use a virtual scroller but:

1. I would lose browser search
2. Results are not ranked by relevance but by position in the Bible. People are often more interested in the last results than the first as the New Testament is at the end of the Bible. Users know the order of books so if they scroll to the middle they would expect to be in Psalms or to the end in Revelation.

Requirements

1. Scrollbar needs to work

   • should be able to drag scrollbar from top to bottom and access verses from Genesis to Revelation.
   • using the scrollbar is akin to flipping through pages in a book (coarse)
   • using scroll wheel, trackpad is for scanning verses (fine)
   • should be seamless moving between the two (like Google maps zoom)
   • this is hard because we have to guess the size of elements that have not been rendered when jumping dragging the scrollbar.

2. Would like to be able to sync scrolling smoothly. e.g. have two panes with different Bible versions that scroll in sync. Or have two people with browsers open at different widths that scroll in sync via web sockets. This is very hard to do without virtual scrolling as it is hard to know what is in the view port without observing every element.

3. Browser in page search needs to work.