IgniteUI / igniteui-webcomponents / 35968466218

99%

push

github

feat(virtual-scroll): recycle item elements, add keyFunction, fix nearest and the size estimate (#2401)

Render the window through a new `recycle` directive instead of a
positional `map`. An item that stays in the window keeps its element, so a
scroll step updates only the items that enter the window. The elements of
the items that leave are reused for the items that enter, in DOM order,
and elements that no item needs wait detached, so a scroll creates no DOM
once the window has its full size. Lit's `repeat` cannot do this: it never
reuses DOM across keys, and in lit-html 3.3.1-3.3.3 its `removePart`
leaves one comment node for each removed item (lit/lit#5010).

- Add `keyFunction`. Without it, the index is the key. With it, an
  element follows its item across sort, insert and remove.
- Replace the estimate of unmeasured items with the average measured
  size. After the first measurements, apply it only while every item
  before the rendered window is measured, so the rendered items do not
  move. Count only the sizes measured since `estimatedItemSize` changed.
- Make `scrollToIndex` with `block: 'nearest'` follow native
  `scrollIntoView`. An item after the viewport now aligns to the end, so
  a scroll to the next item moves one item, not a page.

A moved element needs a new style and layout. Only kept elements could
stay in place, so on a scroll that keeps part of the window, each
recycled element moved from one end of the window to the other, and a
scroll by most of the window moved most of its elements. Select the
elements that stay in place as the heaviest subsequence of all reused
elements that keeps the old DOM order. A kept element weighs 2 and a
recycled one weighs 1, because a recycled element needs a new layout
for its new item anyway. So on a scroll, the kept elements move only
when they are fewer than half the recycled ones, that is, on a scroll
by more than two thirds of the window. With a grid-like template, this
saves up to 9% of the... (continued)

7564 of 7893 branches covered (95.83%)

Branch coverage included in aggregate %.

544 of 550 new or added lines in 5 files covered. (98.91%)

52184 of 52739 relevant lines covered (98.95%)

1498.84 hits per line