Virtualized Picker recalculates its layout several times for each visible option when it opens

Aperta
  • Qualcosa non va?
#10,858 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mangeshraut712 ci sta già lavorando.

Dal 27/10/2026.

  • #10872 di @mangeshraut712 — aperta
  • #10886 di @nwidynski — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
frontend, performance

Direzione di ricerca

Start by reading useVirtualizerItem and tracing its calls to isElementVisible() and getSize(); reproduce the Picker opening with the linked demo and inspect the Chrome Performance recording. The issue describes measuring visible options in a shared pass. Done looks like one layout measurement pass for the visible options and fewer repeated style recalculations and layouts.

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

Descrizione

Provide a general summary of the issue here

When a Picker opens, the browser works out the page's styles and layout several times for each visible option before the list can be drawn, because useVirtualizerItem measures each option separately.

🤔 Expected Behavior?

Opening the Picker should work out the layout once for all the visible options, not repeatedly for each one.

😯 Current Behavior

useVirtualizerItem measures each visible option in its own layout effect. For each one, isElementVisible() calls checkVisibility(), then getSize() clears node.style.height, reads scrollWidth and scrollHeight, and then sets the height value back again. Because each option changes a style and then reads a size, the browser works out the styles and layout again, several times for every option.

In a Chrome developer tools Performance panel recording of it opening, rendering 17 visible options took 133 layouts and about 150 style recalculations. With the CPU slowed down 4x in Chrome 155, the Picker took 227ms to open, and the page became unresponsive for 162ms of that time. It takes about the same time with 125 items as with 250, so it isn't the number of items that's the problem.

💁 Possible Solution

Measure the visible options in one pass. Clear the heights of all the options that need measuring first, then read all their sizes, then put the
heights back, so the browser only works out the layout once.

🔦 Context

I was measuring how quickly some different design systems open a country selector, with the CPU slowed down 4x to roughly match a mid-range phone. React Spectrum's Picker uses virtualization, so I expected it to be one of the fastest, but it was the second slowest to open, and the page was unresponsive for 162ms of the time it took to open up.

On lower-end devices, that pause comes straight after the user clicks the Picker, so it makes the whole app feel slow to respond. Since the issue doesn't depend on the number of items, it affects every Picker, not just ones with long lists, and a fix in seVirtualizerItem would help any app that uses it.

🖥️ Steps to Reproduce
  1. Clone the reproduction repo I made here: https://github.com/denodell/react-spectrum-picker-open-repro
  2. Run npm install, then npm start, and open the page it serves.
  3. In the Performance panel of Chrome's developer tools, set CPU throttling to 4x and press Record.
  4. Click the Picker to open it, then stop the recording.
  5. The main thread shows a long run of short Recalculate style and Layout events, and in the "Bottom-Up" tab, notice that checkVisibility is near the top, called from isElementVisible in useVirtualizerItem.
Version

@adobe/react-spectrum 3.47.6, react-aria 3.53.0, React 19.3.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS Golden Gate

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

Lingua principale
TypeScript
Stelle
16k
Fork
1.6k
Merge medio
2g 17h
PR unite (30g)
41

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 adobe/react-spectrum

Tutte le issue di adobe/react-spectrum

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.