In particular ./layouts/*.js, ./virtual-repeater.js and ./virtual-list.js

VirtualList computes the viewport manually by diffing the scrollTarget bounds with the container bounds. We use getBoundingClientRect() to get scroll position and size, so we force layout.
We might be able to use IntersectionObserver to get the scroll position info w/o causing relayout.
For the size, we can rely on ResizeObserver (#16)

From https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Model/Mastering_margin_collapsing:

The margins of adjacent siblings are collapsed (except when the latter sibling needs to be cleared past floats).

The Layout should manage this when computing positioning, so probably Repeater should provide also child margin information.

I'd like to propose the following API refinement. Currently you do

list.newChild = index => childElement;
list.updateChild = (child, index) => ...;
list.recycleChild = (child, index) => ...;
list.childKey = (index) => key;
list.totalItems = length;
list.requestReset();

I think we should introduce the concept of an "item source" which translates indices into items, like so:

list.newChild = item => childElement;
list.updateChild = (child, item) => ...;
list.recycleChild = (child, item) => ...;

list.itemSource = {
  init(list) { /* see below */ },
  item(index) { return item; },
  get length() { return length; },
  childKey(index) { return key; }
};

list.itemsChanged();

So far this is not very different:

• It groups things related to the items together
• It lets the newChild/updateChild/recycleChild functions go back to operating on items instead of indices, which is somewhat nice
• It changes from a totalItems setter to a getLength() function, which the implementation calls lazily. This means that you can no longer trigger updates by setting totalItems, but must always call itemsChanged() instead.

But this enables us to provide some helpful item source factories:

list.itemSource = new ArrayItemSource(contacts, c => c.name);

contacts.push({ name: "Domenic" }); // doesn't do anything
contacts[1].name = "Valdrin";
list.itemsChanged();                // Let the list know to refresh from the item source

class ArrayItemSource {
  constructor(array, childKey) {
    this._array = array;
    this.childKey = childKey;
  }
  
  item(index) {
    return this._array[index];
  }
  
  get length() {
    return this._array.length;
  }
}

or even

list.itemSource = new SmartArrayItemSource(contacts, c => c.name);

list.itemSource.push({ name: "Domenic" }); // automatically updates the list!

// But, this still needs to be done manually:
list.itemSource[1].name = "Valdrin";
list.itemsChanged();

// But this would work automatically:
list.itemSource[1] = { name: "Valdrin" };

class SmartArrayItemSource extends Array {
  constructor(array, childKey) {
    const normalProto = new.target.prototype;

    const wrapped = new Proxy(array, {
      set(...args) {
        const returnValue = Reflect.set(...args);
        if (array._list) {
          array._list.itemsChanged();
        }
        return returnValue;
      },
      getPrototypeOf() {
        return normalProto;
      }
    });
    
    wrapped.childKey = childKey;
    
    return wrapped;
  }
  
  init(list) {
    this._list = list;
  }
  
  item(index) {
    return this[index];
  }
}

Context: see this note from @atotic on ResizeObserver timing (rAF, then ResizeObserver, then Paint)

Currently we batch rendering with a rAF. This means that a user can expect to have the virtual-scroller rendered by the next frame.

Is it reasonable to explicitly say this

expect virtual-scroller to be done rendering by the next rAF (1)

vscroller.totalItems = 10;
requestAnimationFrame(() => {
  console.log(vscroller.childElementCount);
});

or should we instead say

expect virtual-scroller to be done rendering by the next paint (2)

vscroller.totalItems = 10;
requestAnimationFrame(() => 
  Promise.resolve().then(() => {
    console.log(vscroller.childElementCount);
  })
);

With option (1) we're currently obliged to force reflow on the container, as ResizeObserver callback is invoked after the rAF callback.

Option (2) would allow us to use the ResizeObserver timing as signal to render synchronously. I don't know if there is a "blessed way" for having an afterPaint callback, so we could expose a afterNextRender promise in virtual-scroller to be used exactly for this:

vscroller.totalItems = 10;
vscroller.afterNextRender().then(() => {
  console.log(vscroller.childElementCount);
});

@domenic WDYT?

Right now the items setter just takes whatever its given and stores it. The getter returns the stored value.

The more web-platformey thing to do would be:

• The setter accepts any iterable, snapshotting that iterable at the time it's set
• The getter returns a frozen array of the snapshot

The main benefit here is that you can't write code like

list.items.push(...);

because the array is frozen. (Such code won't work, because there's no notification that the array changed. You'd instead need to use requestReset(): see #26.)

The drawback of this is that it's O(n) in the total number of items. The current requestReset() pattern allows O(1) item additions and removals.

Not sure what to do here, but I wanted to have a tracking issue open.

https://github.com/valdrinkoshi/virtual-list/blob/design/DESIGN.md has a lot of examples where you construct various classes by creating empty versions of them and then setting a bunch of properties with Object.assign(). This is strange in a few ways:

• It implies that the objects are fully functional even before these properties are set. Is that true? I find it hard to believe that a VirtualList with no layout or items is still a fully-functional VirtualList.
• It implies that these properties can be changed at any time and the class will respond appropriately. (E.g., changing container.)
• It implies that these properties can all be changed independently of each other. (Maybe this is true, I'm not sure.)

Instead I would suggest making these constructor arguments: new VirtualList({ layout, container, items, newChildFn }), etc. This ensures that you cannot construct an instance of the class without setting them, and setting them all at once, together.

This also allows more fine-grained separation so that things which can be set and modified later and independently (say, VirtualRepeater's first?) are exposed as public getter/setter pairs.

<virtual-scroller> is the thing that needs to be sized and creates DOM as the user scrolls to it

<virtual-content> is the thing that auto-sizes itself according to the estimated size of the items, and creates DOM only for the visible portion of it (can be contained in any scroll container).

<virtual-list> currently exposes the requestReset() method as a mean to trigger a rerendering of the DOM. This is useful for users that want to keep the same items array instance, perform an arbitrary number of updates to it, and decide when to trigger the rerendering.

Should we expose such method?

Other possible solutions:

1. always trigger the rerendering when items is set
2. require the user to provide a new items array instance to trigger the update

If we want to keep this method, what would be a better name for it?

We should stay consistent with the rest of the platform, and general use these nouns:

• top
• left
• width
• height

The current design sometimes uses "y" instead of "height" (e.g. in itemSize) or "y" instead of "top" (e.g. in scrollTo).

In general we can just use an name for the method, without suffixing it with something indicating its type. Custom elements have a weird "Callback" suffix but that is because of worries about collision with other things on element subclasses; it's not generally a good pattern.

<virtual-scroller> expects new/update/recycleChild methods to return/handle Element nodes, and VirtualRepeater relies on Element native APIs to append/move/remove/measure these.

Other templating engines like lit-html or preact create different types of instances for their rendering purposes, e.g. lit-html deals with TemplateResults, preact with VNodes, and their render() methods know how to convert these into DOM to be stamped in a container.

The current virtual-scroller makes it confusing for the user to deal with both TemplateResults/VNodes and Elements. E.g. this is the most ergonomic way to use virtual-scroller with lit-html/preact http://jsbin.com/secetor/1/edit?html,output

import './virtual-scroller-element.js';
import {html, render as litRender} from './node_modules/lit-html/lib/lit-extended.js';
import {createElement, render as preactRender} from './node_modules/preact/dist/preact.esm.js';

const wrapper = 'div';
const totalItems = 100;

/* -- raw -- */
const rawScroller = (totalItems) => {
  const scroller = document.createElement('virtual-scroller');
  scroller.newChild = (i) => document.createElement(wrapper);
  scroller.updateChild = (el, i) => el.textContent = `index ${i}`;
  scroller.totalItems = totalItems;
  return scroller;
};
const rawRender = (elem, container) => container.append(elem);

rawRender(rawScroller(totalItems), rawContainer);

/* -- lit-html -- */
const litScroller = (totalItems) => html`
    <virtual-scroller
      newChild="${() => document.createElement(wrapper)}"
      updateChild="${(el, i) => litRender(html`index ${i}`, el)}"
      totalItems="${totalItems}"></virtual-scroller>`;

litRender(litScroller(totalItems), litContainer);

/* -- preact -- */
const preactScroller = (totalItems) => createElement(
    'virtual-scroller', {
      newChild: () => document.createElement(wrapper),
      updateChild: (el, i) => el.textContent = `index ${i}`,
      totalItems,
  });

preactRender(preactScroller(totalItems), preactContainer);

How can we make this more ergonomic for the lit-html and preact users? How would that look like?

Both lit-html and preact need to generate instances that are not Element nodes, and to handle how these instances are rendered via their specific render() method, whereas virtual-scroller needs to keep track of the created children, and to append/move/remove/measure them.

@justinfagnani @developit @domenic WDYT?

Toggling the layout from vertical to horizontal should reset the minHeight on the container.
Likewise, toggling from horizontal to vertical should reset the minWidth.

A virtual-scroller is great for infinite scrolling but for SEO purposes it's good to make the pages of data addressable as described here:

https://webmasters.googleblog.com/2014/02/infinite-scroll-search-friendly.html

(and the rangechange event in virtual-scroller makes this much easier to implement! 👍)

Would it be useful to be able to force the n (page size) items to be rendered when in a SSR / bot scenario, regardless of the height of the list container and how many items might otherwise be rendered?

I know it would be possible to just switch to a different template and render things as a plain list but wondered if it might be easier / simpler to just force some fixed item render count as a parameter.

Click on one of the items (in Chrome) and change the text with the keyboard... then scroll, like moving the scrollbar with the mouse - lots of rendering artifacts. At one point I had the same item stay visible always while scrolling

In #13 we moved from setter-only design to constructor arguments.

In <virtual-list> element we chose composition over inheritance. We lazily init a VirtualList once the user provides the newChild method through the <virtual-list>.template setter.

Rather than having the template setter, we could introduce an init(config) method where the user can pass the child templating methods, e.g.

document.querySelector('virtual-list').init({
  newChild: (item, idx) => {
    const child = document.createElement('div');
    child.textContent = idx + ' - ' + item;
    return child;
  },
  // updateChild: ...,
  // recycleChild: ...,
  // direction: 'horizontal',
  // items: []
});

<virtual-scroller> positions children with position: absolute and sets their width: 100%, so if the virtual-scroller has padding, children would effectively get the total width of their container (padding included). The user would have to handle that e.g. like this:

virtual-list {
  padding: 10px;
}
virtual-list > * {
  width: calc(100% - 20px);
}

See if we can do something to handle padding too, or at least document this limitation

We currently measure each child's bounds and margins during rendering, this tho could be provided by the user who knows the size, making the list rendering even faster.

childSize(child: Element, index: number) => { width, height, 
                                              marginTop, marginBottom,
                                              marginLeft, marginRight }

Here an example usage:

virtualList.newChild = (index) => {
  const el = document.createElement('div');
  el.style.height = '50px';
  el.style.marginTop = '10px';
  el.textContent = index;
  return el;
};

virtualList.childSize = (child, index) => {
  const size = { height: 50 };
  if (index !== 0) size.marginTop = 10;
  return size;
};

virtualList.totalItems = 10;

The rendering of the HTML spec is only sized to the viewport of the browser when the header (chrome with address bar) is visible

e.g. https://developer.mozilla.org/en-US/docs/Web/API/Event/Event

Currently <virtual-list> styles its host with contain: strict to help the browser reduce the layout/paint/style computations.

One of the drawbacks is that content intentionally overflowing outside the virtual-list will be clipped, e.g.

<style>
  virtual-list {
    width: 200px;
  }
  .tooltip {
    position: absolute;
    top: 0;
    left: 180px;
  }
</style>
<virtual-list id="list"></virtual-list>
<script>
  list.newChild = () => {
    const child = document.createElement('div');
    child.innerHTML =`
     <span>Hello world!</span>
     <span class="tooltip">custom tooltip</span>`;
   return child;
  };
  list.items = new Array(100);
</script>

The user can still override the default value via css, e.g. virtual-list { contain: none; }, and we could also expose a css custom property.

Before doing that, is it worth for <virtual-list> to set this default style?

In #83 we'd like to know when the scroll event was caused by user action vs when it was caused by resize events.

We want to invalidate anchoring information when user scrolls, and compute (if needed) and use the anchoring information on size changes.

For most of the cases diffing the previous scroll position with the new one is enough. This tho doesn't work in the following case: the user scrolled at the bottom of the list, and now resizes the window to make it larger:
=> the items occupy less height
=> the container scrollHeight decreases, hence the browser adjusts the scrollTop to be scrollTop = scrollHeight - offsetHeight
=> this provokes a scroll event
=> the diffing of the previous scroll position with the new one considers this as a user scroll 😭🔫

Here a simplified example where we change the size of items above the last one http://jsbin.com/vejuzo/1/edit?html,output

The only way to handle this i can think of is to ignore the scroll events when we detect a size change, and to stop ignoring them after a setTimeout(fn, 1) 🤢

Edit: Another idea is to adjust the scroll position when we receive the new viewport size - so that the diffing will result in no changes 💡

@domenic @graynorton any ideas? This seems a good candidate for missing platform features maybe.

It's better to use a simple static server if we can, instead of something tied to a particular framework.

The Repeats mixin keeps track of the created DOM in the key/child map _keyToChild. When a child is not found, it will invoke newChild to create it and stores it in the _keyToChild map.
In this example newChild is invoked only for the newly added item, while updateChild is invoked for all the items:

list.items = list.items.concat({name: 'new item'});

_keyToChild uses index as the key. This can be customized by providing the itemKey function to return a custom key itemKey(item: any) => string|number

Should we expose this property in <virtual-list>?

Per #48 (comment), apparently virtual-list only reads from the items array after a microtask delay. This is pretty unusual, and I think we should discuss it.

In particular, the example discussed there is pretty confusing. Consider a list where you have only set newChild. If you do

// (1)
list.items = x;
list.items = y;

then it will call newChild for all the items in y. But if you do

// (2)
list.items = x;
setTimeout(() => {
  list.items = y;
}, 0);

Then it will call newChild for all the items in x, and the items in y are ignored. I would prefer that both are consistent: i.e. both do newChild for all items in x.

Now consider a list where you have set both newChild and updateChild. Then (1) will call newChild + updateChild for all the items in y, and (2) will call newChild for all the items in x, and updateChild for all the items in y. I would prefer that both are consistent: i.e. both do newChild for all items in x, and updateChild for all items in y.

Note that the platform has some precedent for delayed rendering. img.src = x; img.src = y; will only try to load y. This case feels worse because of the newChild/updateChild distinction, though.

MutationObservers are also microtask-batched, but they don't do coalescing, so they tell you all the things that happened since the last time, not just the latest thing.

I'm open to being convinced that batching is more important than consistency. But I lean toward saying that if developers change items a lot, they should know that will cause a lot of updates, and we shouldn't try to batch for them.

Maybe if developers want batching, we should have something more suited to their use case, e.g.

const resumeUpdates = list.suspendUpdates();
... mutate list.items a lot ...
resumeUpdates();

Also, if we do think batching is important, I think microtask batching is probably not right, and we should do requestAnimationFrame batching instead.

Thoughts?

Prepare demo to showcase a fallback UI while loading items

Looking at the main readme, there doesn't seem to be a way to programmatically scroll to a given item.

This is very useful in some contexts.

As you need to set updateElement before calling requestReset, wouldn't requestUpdate not be a more explaining name? It would also make it more clear that you had to implement updateElement.

invalidate would be another suggestion, though that doesn't show the link with updateElement.

request to me sounds like something that might be rejected. scheduleUpdate? Maybe that is why I like something like invalidate

When the list items have variable height, the user can notice a "jumpy" scrollbar behavior while scrolling.
This is caused by the error adjustment done by the Layout. This should be mitigated by memoizing the sizes.
e.g.

import Layout from './layouts/layout-1d.js';
import {VirtualList} from './virtual-list.js';

const vlist = new VirtualList();
vlist._recycledChildren = [];

Object.assign(vlist, {
  items: new Array(20).fill({name: 'item'}),
  container: document.body,
  layout: new Layout(),

  newChildFn: (item, idx) => {
    let section = vlist._recycledChildren.pop();
    if (!section) {
      section = document.createElement('section');
      section._title = section.querySelector('.title');
      // Update it immediately.
      vlist._updateChildFn(section, item, idx);
    }
    return section;
  },

  updateChildFn: (section, item, idx) => {
    section.style.height = (100 * (idx + 1)) + 'px';
    section.style.outline = '1px solid';
    section.id = `section_${idx}`;
    section.textContent = `${idx} - ${item.name}`;
  },

  recycleChildFn: (section, item, idx) => {
    vlist._recycledChildren.push(section);
  }
});

The html spec stylesheet styles elements with selectors like body > p, hence hosting the content inside <html-spec-viewer> breaks these styles.

Right now the code loads layouts dynamically. I'm not sure that makes much sense for something that would be bundled with the browser.

But maybe it does? After all, you still pay some cost for loading the layouts in to memory, and maybe you should only pay those costs for layouts you use. I'm not sure.

From a spec perspective, I guess the impact of loading layouts lazily is that we'd have to mandate in the spec that changing the layout can take an arbitrarily long time to apply (e.g. if loading them takes longer than one animation frame). That seems a bit bad.

Currently <virtual-list> supports only the main document as scrolling element. Ideally we'd want to allow the user to setup another scrolling element.

We could check the css overflow property of the container, and if it is scroll or auto then the container is the scrolling element

<virtual-list> can leverage the default behavior of display: block which will take all the available width.
http://output.jsbin.com/beqigu/1/quiet
http://jsbin.com/beqigu/1/edit?html,output

newChild function is invoked when the <virtual-list> needs DOM to represent an item.

recycleChild function is invoked when the <virtual-list> has already set display: none on the child and is about to remove it from the document. if not defined, <virtual-list> will remove the child from the document. The user can use this property to stop the default behavior and manage the DOM.
When defined, <virtual-list> will not remove the child from the document to avoid a removeChild/appendChild sequence for performance reasons. The user can still decide to remove the child from the document in the recycleChild function.

updateChild function is invoked after the <virtual-list> has appended the child to the container and requires it to be updated with data.

1. Is there a better name that conveys the intent of these functions?
2. shoulde we fire an event instead of recycleChild? Something like willremovechild? We'd still need a way to know that it was handled (e.g. via preventDefault()) in order to prevent the removal of the child from the document.
3. do we really need updateChild? the user could just use newChild and recycleChild

const vList = document.querySelector('virtual-list');
const pool = [];
Object.assign(vList, {
  items: new Array(20).fill('item'),
  newChild: (item, idx) => {
    const child = pool.pop() || document.createElement('div');
    child.textContent = idx + ' - ' + item;
    return child;
  },
  recycleChild: (child, item, idx) => {
    pool.push(child);
  }
});

^ We need updateChild for cases like data updates w/o changing first, num

A pattern of "protected methods" that are prefixed with _ is not present on the web platform.

Instead, I'd suggest making these kind of customizations constructor arguments, similar to #8. You can see precedent for this in various places on the platform, such as promises and streams.

I might not fully be understanding these though, as I don't see why you used one design for _measureCallback and one for updateChildFn.

itemKey(item: any) => any is used to determine an identifier for the DOM corresponding to the array item.
We should probably rename it to childKey, as it is effectively a sort of "id" for the stamped dom.

We could name it childId, but that might lead users to think that the generated dom has an id attribute.

I had to change virtual-list-element.js:167 in order to load modules when bundling with rollup.

patch-package
--- a/node_modules/virtual-list/virtual-list-element.js
+++ b/node_modules/virtual-list/virtual-list-element.js
@@ -164,7 +164,7 @@ export class VirtualListElement extends HTMLElement {
     Object.assign(list, {newChild, updateChild, recycleChild, itemKey, items});

     const Layout = await importLayoutClass(
-        this[_grid] ? './layouts/layout-1d-grid.js' : './layouts/layout-1d.js');
+        this[_grid] ? '/node_modules/virtual-list/layouts/layout-1d-grid.js' : '/node_modules/virtual-list/layouts/layout-1d.js');
     const direction = this[_horizontal] ? 'horizontal' : 'vertical';
     if (list.layout instanceof Layout === false ||
         list.layout.direction !== direction) {

See #27

Your deployment/demo link needs update after you added the template stuff.

When scrolling, recycleChild gets called after newChild, so the user would collect children too late to be reused for that render loop.

This seems caused by the fact that we enter in _incremental mode during rendering, which doesn't invoke recycleChild but does always invoke newChild.

<virtual-list> positions its children with position: absolute and transform: translate3d.
Should it also style the children with will-change: transform by default?

There are some implications for animations, e.g. see section "Partial solution: set will-change: transform" here https://greensock.com/will-change
This might be mitigated by the fact that we need to position children with position: absolute, hence we're creating a stacking context for each.

VirtualList positions children via translate2d with values that have subpixel precision. This seems to cause some weird artifacts like blurriness (seen on Canary on the html-spec-viewer)

Figure out if need to avoid subpixel or we can use some magic css property.

browser

Firefox develop lastest

console

SyntaxError: expected expression, got keyword 'import'[详细了解]
virtual-list-element.js:20:26

To reproduce

• go to https://valdrinkoshi.github.io/virtual-list/demo/contacts/
• scroll down a couple items
• resize the window
• note that the scroll position gets offset by items changing their size

https://github.com/valdrinkoshi/virtual-list/blob/design/DESIGN.md#layout has a method named addListener.

Is this just a typo, and it should be addEventListener? Or did we invent a new evening system? We definitely don't want to be shipping a second eventing system with the browser, so if it's the latter, please move to inheriting from EventTarget and using the standard eventing system instead.

Adding this jsbin template here for people to play with
http://jsbin.com/cibopekiqe/1/edit?html,output

Tracker for the features to be implemented - copied from https://github.com/domenic/infinite-list-study-group/edit/master/REQUIREMENTS.md.

Mark complete after providing implementation and documentation.

P0

• Accurate scrollbar position for elements that have been loaded
  • Implemented, see demo/layout.html (scroll, change items count, and observe scroll position is kept)
• Overall list structure supports screen readers and accessibility controls
• Heterogeneous elements
  • Controlled by the user via newChild property
• Fallback element UI
  • Controlled by the user via newChild property
  • see demo/fallback.html
• Grid layout
  • <virtual-list layout="vertical-grid"></virtual-list>
  • see layout property
• List headers/footers
  • Controlled by the user via newChild property
  • see demo/header-footer.html
• Configurable layout and style for elements in the list
  • User can style content via virtual-list > * or by adding arbitrary classes to the stamped children
  • layout configurable via the layout property
• Clickable list elements
  • Controlled by the user via newChild/updateChild properties
  • example in the README.md
• indexability of not loaded content

P1

• Find in page (ctl+F) highlights elements that have been loaded
• Sub groups within the list (i.e. letter groupings for a contact list)
  • see demo/header-footer.html
• Maintain scroll position across page load
• "Load more" button
  • see demo/loadmore.html
• Ability to animate items in/out, changing sizes
  • see demo/dismissable/index.html

P2

• Backed by remote data source
  • demo/fallback.html shows how contacts are lazily loaded while we place a fallback during the loading
• Selectable list elements
  • TODO demo/selection.html
• Rearrangeable list
• Find in page (ctl+F) highlights all elements in the list that haven't been loaded
• Accurate scrollbar position including elements that haven't been loaded
• Pull to refresh
  • TODO demo/pulltorefresh.html
• Discoverable by screen readers for elements in the list that haven't been loaded
• anchor refs pointing to dom not yet rendered
• Horizontal scrolling
  • <virtual-list layout="horizontal"></virtual-list>
  • see layout property in the README.md

Demo showcasing a virtual-list with headers/footers

Neither VirtualRepeater nor VirtualList actively use items or mark in any way the objects in the array, so it should be possible to setup a list with only totalItems (number) instead of items (array). This would translate in a setup like this:

const items = new Array(10).fill('item');

/* old setup with items (array) */
new VirtualRepeater({
  items: items,
  newChild: (item, idx) => document.createElement('div'),
  updateChild: (child, item, idx) => child.textContent = `${idx} - ${item}`,
  childKey: (item) => item.key
});

/* new setup with totalItems (number) */
new VirtualRepeater({
  totalItems: items.length,
  newChild: (idx) => document.createElement('div'),
  updateChild: (child, idx) => child.textContent = `${idx} - ${items[idx]}`,
  childKey: (idx) => items[idx].key
});

One drawback of this approach is that we cannot check anymore for identity in the totalItems setter, meaning that we'd have to always reset the list when totalItems is set, whereas with items we could check for strict identity in order to trigger the reset.

What about setting these default values for newChild and updateChild?

constructor() {
  super();
  this.newChild = () => document.createElement('div');
  // assuming we have itemsSource API
  this.updateChild = (child, item) => child.innerHTML = item.toString();
}

The user can still override these values to customize the scroller.

A default newChild helps especially those template libraries that need a container to render within, e.g. lit-html and preact. With lit-html, the user would just need to do this to update the nodes:

import {render, html} from './node_modules/lit-html/lib/lit-extended.js';
import './virtual-scroller-element.js';

const itemTemplate = (item) => html`item ${item.someproperty}`;
const updateChild = (child, item) => render(itemTemplate(item), child);

const scrollerTemplate = (totalItems) => html`
   <virtual-scroller updateChild=${updateChild} totalItems=${totalItems}>
   </virtual-scroller>`;
      
render(scrollerTemplate(1000), document.body);

If we want wide adoption of this pattern, it'd be nice if there was a way to extend it to at least 2 dimensions - think something like a spreadsheet or a map of tiles or some other virtually infinite 2-dimensional structure.