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

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

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

@rubenmarcus y travaille déjà.

Depuis le 30/9/2026.

  • #1517 par @rubenmarcus — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
42/100
Type d'issue
Bug
Clarté
À clarifier
Activité
Calme
Stack technique
react, typescript
Domaine
frontend, performance

Piste de recherche

Commencez par Body/MeasureCell.js et useResizeObserver.js:20, puis reproduisez un tableau à en-tête fixe avec scroll.y et profilez son cold mount comme indiqué. Le travail est terminé lorsqu’il est déterminé si les lectures par colonne sont intentionnelles et qu’un chemin de mesure moins coûteux est identifié ou implémenté sans modifier le comportement observé du tableau.

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

Description

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.

Langage dominant
TypeScript
Étoiles
1.4k
Forks
619
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

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

Toutes les issues de react-component/table

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.