Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

lit-virtual: VirtualizerController never applies updated options after construction

Geschlossen
  • Stimmt etwas nicht?
#1,251 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@itisrmk arbeitet bereits daran.

Seit 20.10.2026.

  • #1253 von @waterWang — ohne Merge geschlossen
  • #1334 von @itisrmk — offen

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
typescript
Bereich
frontend

Rechercherichtung

Beginne mit packages/lit-virtual/src/index.ts und verfolge, wie VirtualizerController während der Konstruktion Optionen erhält und während hostUpdated() aktualisiert wird. Vergleiche die im Issue erwähnten Adaptermuster von react-virtual, angular-virtual und lit-table und definiere anschließend einen Pfad zur Aktualisierung von Optionen, dessen vollständiges Verhalten geänderte Werte wie count bei nachfolgenden Renderings anwendet.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Describe the bug

VirtualizerController (packages/lit-virtual/src/index.ts) never calls setOptions() after the initial construction, so reactive option updates (a changed count, estimateSize, getScrollElement, etc.) never reach the underlying Virtualizer instance.

constructor(
  host: ReactiveControllerHost,
  options: VirtualizerOptions<TScrollElement, TItemElement>,
) {
  ...
  this.virtualizer = new Virtualizer(resolvedOptions) // options captured once, here
  ;(this.host = host).addController(this)
}

hostUpdated() {
  this.virtualizer._willUpdate() // no setOptions() call
}

Every other adapter calls setOptions() on every render/update before _willUpdate(). For comparison, react-virtual's useVirtualizer:

instance.setOptions(resolvedOptions)
...
return instance._willUpdate()

and angular-virtual:

virtualizer.setOptions(resolvedOptions())
...
reactiveVirtualizer()._willUpdate()

lit-table's equivalent TableController (same Lit ReactiveController shape, different package) does call the table-core equivalent of setOptions on every access, so this isn't a Lit-specific limitation, lit-virtual just doesn't do it.

Since VirtualizerController is meant to be instantiated once in the host's constructor (the documented usage pattern, same as any other Lit ReactiveController), there's no way for a consumer to get a changed count or other option applied short of reaching into getVirtualizer() and calling .setOptions() manually, which isn't documented anywhere and defeats the point of passing options to the constructor in the first place.

Your minimal, reproducible example
import { LitElement, html } from 'lit'
import { VirtualizerController } from '@tanstack/lit-virtual'

class MyList extends LitElement {
  count = 10

  virtualizerController = new VirtualizerController(this, {
    count: this.count,
    estimateSize: () => 35,
    getScrollElement: () => this.renderRoot.querySelector('#scroller'),
  })

  grow() {
    this.count = 1000
    this.requestUpdate()
  }

  render() {
    const virtualizer = this.virtualizerController.getVirtualizer()
    // virtualizer.options.count is still 10 after grow(), even though
    // this.count is 1000 and the component re-rendered
    return html`<div id="scroller">${virtualizer.getVirtualItems().length} items</div>`
  }
}
Steps to reproduce
  1. Create a VirtualizerController with an initial count.
  2. Change the value backing count and call requestUpdate() on the host.
  3. Read virtualizer.options.count (or observe the rendered item count), it still reflects the value from construction time.
Expected behavior

Option changes on subsequent renders should reach the virtualizer, the same as every other framework adapter.

Worth noting this needs more than adding a setOptions() call inside hostUpdated(): the constructor is the only place options is ever received (options: VirtualizerOptions<...>, not a getter), so even a hostUpdated() call would just re-apply the same closed-over object from construction time. The API shape itself doesn't have a channel for fresh options to flow in after construction. lit-table's TableController sidesteps this by exposing a .table(tableOptions, selector) method that's called fresh from render() on every pass rather than once from the constructor, that shape (or an equivalent public setOptions() method consumers call from render()) looks like the fix, not just wiring hostUpdated() to an already-stale value.

Platform

n/a, framework-adapter logic (packages/lit-virtual/src/index.ts)

Vorherrschende Sprache
TypeScript
Sterne
7.2k
Forks
479
Ø Merge
21 Std. 1 Min.
Gemergte PRs (30 T.)
41

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/virtual

Alle Issues in TanStack/virtual

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.