Skip to content

startEditing re-renders every row — ~300ms edit-entry latency on a 140-row non-virtualized grid #88

Description

@zvndev

Problem

Entering edit mode on a single cell (startEditing) re-renders and re-lays-out every row in the table — editing state lives in the table store and every row subscribes. Measured on a 140-row grid with pinned columns + sticky header: ~300 ms click→editor-focused, and that floor persists after memoizing all app-side cell renderers (confirming the cost is per-row reconciliation + full-table layout, not app cells).

Compounding constraint

The natural mitigation is row virtualization, but virtualization currently breaks sticky pinned body cells (#83) — so a grid that needs pinned columns is forced into non-virtualized rendering AND pays the full-table re-render on every edit entry. The two limitations compound: pinned columns ⇒ no virtualization ⇒ O(rows) edit-entry latency.

Suggested fix

Scope editing-state subscriptions so only the affected row/cell re-renders (per-row selector or per-cell store slice), and/or fix #83 so virtualization can bound the row count.

Repro numbers

140 rows, ~14 columns, edit any numeric cell: ~300-310 ms median click→focus. Same grid, rows whose cells contain ~7 interactive controls each: 416 ms before app-side React.memo, 188 ms after — the remainder is the all-rows re-render.

Versions: yable-react 0.10.4 / yable-core 0.9.0, React 19.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions