Fixed-header tables force one getBoundingClientRect per column on every mount (ResizeObserver-driven MeasureCell)

Aperta
#1,507 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
react, typescript
Ambito
frontend, performance

Direzione di ricerca

Inizia da Body/MeasureCell.js e useResizeObserver.js:20, quindi riproduci una tabella con intestazione fissa e scroll.y e profila il suo cold mount come descritto. Il lavoro è completato quando viene determinato se le letture per colonna sono intenzionali e viene identificato o implementato un percorso di misurazione a costo inferiore senza modificare il comportamento osservato della tabella.

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

Descrizione

Environment

  • @rc-component/table: 1.10.4 (via antd 6.5.3)
  • @rc-component/resize-observer: 1.1.2
  • Chrome, production build, 4x CPU throttle (DevTools)

What we observed

Any table mounted with a fixed/scrollable header (scroll.y set, i.e. fixHeader true) renders a hidden "measure row" with one MeasureCell per column. Each MeasureCell wraps its cell in a ResizeObserver (Body/MeasureCell.js), and on the initial observe, onInternalResize (useResizeObserver.js:20) calls target.getBoundingClientRect() once per cell.

On a ~40-column table, we measured 86 getBoundingClientRect calls totaling ~547ms of forced-layout self-time on a single cold mount, instrumented by wrapping HTMLElement.prototype.getBoundingClientRect/offsetWidth and measuring with performance.now(). This is currently the dominant forced-layout cost on table mount in our app (a general-purpose ERP list view), well above what column count alone would suggest — the reads don't appear to be batched into a single reflow.

Question / ask

Is per-column ResizeObserver-driven measurement (as opposed to reading all column offsetWidths in one synchronous batch, which the browser can usually satisfy with a single layout pass) intentional, or is there a lower-cost path we're missing (e.g. skipping remeasurement when explicit pixel widths are already provided for every column)? Happy to share a minimal repro or profiling trace if useful.

Lingua principale
TypeScript
Stelle
1.4k
Fork
618
Merge medio
10h 19m
PR unite (30g)
2

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

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 react-component/table

Tutte le issue di react-component/table

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.