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

Abierto
  • ¿Algo no está bien?
#10,858 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@mangeshraut712 ya está trabajando en esto.

Desde el 27/10/2026.

  • #10872 de @mangeshraut712 — abierto
  • #10886 de @nwidynski — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
react, typescript
Área
frontend, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
16k
Forks
1.6k
Merge medio
2 d 19 h
PR fusionados (30 d)
41

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de adobe/react-spectrum

Todos los issues de adobe/react-spectrum

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.