Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

lit-virtual: VirtualizerController never applies updated options after construction

Fermée
  • Quelque chose ne va pas ?
#1,251 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@itisrmk y travaille déjà.

Depuis le 20/10/2026.

  • #1253 par @waterWang — fermée sans fusion
  • #1334 par @itisrmk — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
typescript
Domaine
frontend

Piste de recherche

Commencez par packages/lit-virtual/src/index.ts et suivez la manière dont VirtualizerController reçoit les options lors de sa construction et les met à jour pendant hostUpdated(). Comparez les modèles d’adaptateur react-virtual, angular-virtual et lit-table mentionnés dans l’issue, puis définissez un chemin de mise à jour des options dont le comportement final applique les valeurs modifiées, telles que count, lors des rendus suivants.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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)

Langage dominant
TypeScript
Étoiles
7.2k
Forks
479
Merge moyen
1 j 5 h
PR mergées (30 j)
38

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TanStack/virtual

Toutes les issues de TanStack/virtual

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.