Closed trusktr closed 4 years ago
Having the elements in the DOM is an explicit goal. Elements not in the DOM are not indexable, findable with ctrl-f or accessible to screenreaders etc.
https://github.com/WICG/virtual-scroller/blob/master/README.md#why-a-virtual-scroller
There are lots of existing virtual scrollers that do exactly what you're proposing.
Something I'm thinking is that if we write
then we will be taxing the DOM system by adding so many elements (JS engine having to cross into the DOM engine, etc).
What virtual scrollers in frameworks like React, etc, do is they do not stick all elements into the DOM, they only stick (for example) 10 or 20 elements at a time depending on where we are scrolled to.
So if the
virtual-scroller
scroller API will need to have all 10,000 elements appended to the DOM, this will already be super heavy and expensive compared to other solutions.I imagine
virtual-scroller
(at least in the polyfilled implementation) would need to set properties likevisibility: hidden
ordisplay: none
and keep track of layout, etc. This may be heavy for thousands of elements (compared to the libs).Can we instead make it an API where we can specify data items (an array) and tell it what to render for each item, f.e. something like
This way, the inner DOM of virtual-scroller is entirely virtualized by being represented with non-DOM data (f.e.
someArray
of data in this case), and only 10 or 20 of the elements specified byelement=""
are placed into the DOM at a time, and thefor-each
is a function that takes each DOM element created and applies data to it from the array.It would then be possible that authors could use React, Vue, jQuery, etc, within the for-each to apply the data to each element.
In a JS environment, we could also avoid global scoping of the
for-each
attribute, f.e.where now the function has lexical scope instead of global scope (similar to
onclick
, etc, attributes).With something like a
virtualScroller.forEach
feature to describe the data manipulation for each element, then a JSX user (f.e.) could writeThey'd still enjoy their framework of choice, but let the virtual scrolling be handled natively.