Coder Social home page Coder Social logo

infinite-list-study-group's Introduction

infinite-list-study-group's People

Contributors

domenic avatar drufball avatar kevinpschaaf avatar mmalerba avatar valdrinkoshi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

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

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.

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.