Data Tables and Grids

Pathrule3 Rules • 1 Memory • 1 Skill

Data tables and grids combine server queries, dense rendering, focus, selection, editing, and accessibility, so small inconsistencies become lost work or unusable navigation. This bundle defines authoritative query state, stable row identity, bounded rendering, grid semantics, edit concurrency, and test procedures. Unlike TanStack Query, it owns the interactive grid contract rather than general remote-data fetching and cache behavior.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

test-data-grid

src/

routes/

Keep the server query as one canonical state

components/

tables/

Use stable row identity for selection and editing

Choose table or grid semantics with the keyboard model

api/

Edits carry row version and field intent

Rules

Keep the server query as one canonical state/src/routeshighstrictSorting, filtering, pagination, grouping, and search resolve from validated URL state into one server query contract.

1	Sorting, filtering, pagination, grouping, and search resolve from validated URL state into one server query contract. Mixing local table state with server paging can sort only the visible page, reset filters unexpectedly, and produce links that do not reproduce the view. Enforce this boundary in /src/routes so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Parse column, direction, filter, cursor or page, and page size against an allowlist before constructing the backend request.
4	- Reset or preserve pagination deliberately when filters and sorting change, and use replace versus push according to history behavior.
5	- Include normalized query state in cache identity and response metadata so the table can detect stale pages.
6	- Keep unsupported and sensitive fields out of client-selectable sort and filter expressions.
7
8	Verification: Open copied URLs, navigate history, change filters during requests, and request invalid columns; confirm view, cache, and server query remain equivalent.

Use stable row identity for selection and editing/src/components/tableshighstrictSelection, expansion, focus, optimistic edits, and virtualization key records by immutable domain identifiers.

1	Selection, expansion, focus, optimistic edits, and virtualization key records by immutable domain identifiers. Array indexes and visible positions change under sort, filter, pagination, insertion, and virtualization, causing actions to target the wrong record. Enforce this boundary in /src/components/tables so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Require a stable row key from the data contract and never synthesize it from position or mutable display fields.
4	- Define whether selection spans pages and filters, then store selected IDs plus an explicit all-matching representation when needed.
5	- Authorize bulk actions against current server state and return per-record outcomes rather than trusting the client's selected count.
6	- Preserve focus by row and column identity when the viewport recycles elements.
7
8	Verification: Sort, filter, insert, remove, paginate, virtualize, and refresh while rows are selected or edited; confirm every action stays attached to the original record.

Choose table or grid semantics with the keyboard model/src/components/tableshighstrictStatic tabular content uses native table semantics, while an interactive grid implements managed focus and documented key behavior completely.

1	Static tabular content uses native table semantics, while an interactive grid implements managed focus and documented key behavior completely. Adding role=grid without roving focus, arrow navigation, cell labeling, and edit transitions can make content harder to use than a native table. Enforce this boundary in /src/components/tables so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Prefer a native table when cells mainly present information and ordinary links or controls can remain in the page tab order.
4	- For a composite grid, keep one tab stop, implement arrow, Home, End, and documented selection behavior, and expose row and column context.
5	- Define how focus enters editable cell content and returns to grid navigation without stealing standard text-editing keys.
6	- Keep offscreen virtual rows represented with accurate counts and positions where the accessibility API requires them.
7
8	Verification: Test native and grid variants with keyboard only, screen reader, zoom, virtualization, editing, empty state, and dynamic row insertion; verify focus never disappears.

Memories

Edits carry row version and field intent/src/apiA grid often shows data long enough for another user or job to change it, so submitting the whole stale row can overwrite unrelated updates.

1	A grid often shows data long enough for another user or job to change it, so submitting the whole stale row can overwrite unrelated updates. Send the stable row identifier, changed fields, and observed version or validator to the mutation boundary.
2
3	Reject or merge conflicts according to explicit field semantics and return current authoritative values. Keep optimistic UI reversible and preserve the user's draft when the server rejects a conflict. Report partial bulk outcomes per record so retries do not repeat successful changes. Keep the decision explicit at /src/api; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /src/components/tables for draft and focus state and /src/routes for query identity. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

test-data-grid/rootTest a data table or grid across query state, identity, keyboard access, virtualization, editing, and degraded networks.

1	---
2	name: test-data-grid
3	description: Test a data table or grid across query state, identity, keyboard access, virtualization, editing, and degraded networks.
4	---
5
6	# Test Data Grid
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Create fixtures with stable IDs, duplicate labels, long text, empty values, mixed directions, large row counts, permissions, and concurrent versions.
11	2. Exercise sort, filter, page, history, selection, expansion, resize, and virtualization while requests overlap, fail, retry, and resolve out of order.
12	3. Run the documented keyboard model and screen-reader flow through headers, cells, editing controls, bulk actions, empty state, errors, and restored focus.
13	4. Race edits and bulk actions against server changes; verify conflict handling, optimistic rollback, per-record results, and no action targets a recycled row.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Why this pattern

Agents render thousands of rows, key by array index, mix client and server sorting, or add ARIA grid roles without implementing the required keyboard and focus model.

Built for Frontend teams building sortable, filterable, selectable, editable, or virtualized data grids.

Keeps your assistant from:

Selection and edits moving to another row after sorting
Client sorting a single page while the server owns the full dataset
Grid roles that trap focus or hide cells from assistive technology

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25