Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

lit-virtual: VirtualizerController never applies updated options after construction

Aperta
  • Qualcosa non va?
#1,251 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@waterWang ci sta già lavorando.

Dal 12/8/2026.

  • #1253 di @waterWang — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
frontend

Direzione di ricerca

Inizia da packages/lit-virtual/src/index.ts e segui come VirtualizerController riceve le opzioni durante la costruzione e le aggiorna durante hostUpdated(). Confronta i pattern degli adapter react-virtual, angular-virtual e lit-table menzionati nell’issue, quindi definisci un percorso di aggiornamento delle opzioni il cui comportamento completato applichi i valori modificati, come count, nei render successivi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
TypeScript
Stelle
7.1k
Fork
472
Merge medio
1g 14h
PR unite (30g)
18

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TanStack/virtual

Tutte le issue di TanStack/virtual

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.