[IzumiSy]

Motivation

DataTable combines rendering, filtering, cell editing, browser measurement, and table-level state in a few oversized files. This makes individual features difficult to navigate and changes harder to review without reading unrelated behavior.

The largest test suites also mix unrelated feature contracts. Aligning test ownership with the implementation boundaries makes the relevant assertions easier to find for both human and AI-assisted changes, without reducing integration coverage.

Split these responsibilities into cohesive internal modules while keeping the existing public API, rendered output, persistence, and interaction behavior unchanged.

Design Decision

Keep feature ownership explicit

Group filtering and editing in feature-local directories with short filenames. Keep shared cell-value helpers outside editing because read-only renderers use them too, and keep the sticky column footer separate from the public pagination/bulk-action footer.

Nest the cell dispatcher, shared UI, editor branches, and related tests under editing/cell/. Use root.tsx, typing.tsx, choice.tsx, and date.tsx without repeating the directory's cell context in filenames. Navigation and edit-session hooks remain directly under editing/.

Extract existing state and measurement logic rather than introducing a generic state framework or additional providers. The public DataTable namespace and useDataTable return shape remain unchanged.

Match tests to behavior, not arbitrary file size

Retain public-composition harnesses and organize suites around meaningful features: menus, headers, column layout, cell rendering, row expansion, filter surfaces, and editor input modes. Reuse the existing selection, styling, choice, and date suites instead of introducing parallel destinations for the same concern.

Keep table-level state and composition checks in data-table.test.tsx, cross-surface filter IME behavior in filters/filters.test.tsx, and cross-editor interactions in editing/cell/root.test.tsx. Share only repeated fixtures and interaction helpers; test lifecycle cleanup stays explicit in each suite.

Preserve existing cases and assertions rather than replacing integration coverage with isolated unit tests. Leave the snapshot-bearing footer test at the family root so its snapshot path and contents remain unchanged.

Summary

• Separate table composition, rendering, column layout, menus, expansion, and DOM measurement into focused modules.
• Extract filtering into filters/ and cell UI with matching tests into editing/cell/, while keeping navigation and edit-session hooks at editing/.
• Extract column, selection/bulk-action, and expansion state hooks and reuse the existing column-key rule.
• Reorganize oversized test suites by feature, consolidate related cases into existing suites, and share minimal feature-local fixtures while preserving test identities and assertions.
• Retain public exports, dependencies, and snapshots; no consumer migration or changeset is needed for this internal-only refactor.