feat(data-table): rebuild as typed dual-engine virtualized grid

[pras75299]

Type

• New component / block (registry)
• CLI change (init / add / list / info / doctor / search / shadcn JSON)
• Docs site (apps/www)
• Build / scripts / CI
• Bug fix
• Refactor / chore

Summary

Rebuilds DataTable as a typed, dual-engine grid: a standard DOM engine for small/grouped datasets and a virtualized engine for large ones, with automatic mode-switching. Adds column presets, multi-column sorting, grouping with collapsible group rows, and row selection so the component scales from tens to ~100k rows without consumers wiring up a third-party table library.

Test plan

• pnpm test (full turbo suite — 22 data-table tests + all workspaces pass via precommit hook)
• apps/www lint (precommit hook)
• pnpm build:registry
• Manually verified in apps/www dev server

---

New component checklist

Registry sources

• registry/data-table/component.tsx
• registry/components/data-table.json — registry + docs blocks
• Slug present in order / docsOrder in registry/manifest.json
• Demo present
• pnpm build:registry artifacts in sync

Component quality gate

• "use client" where needed
• Accepts className and merges via cn
• Props extend correct DOM type, conflicting handlers omitted
• Keyboard operable + aria-sort on sortable headers
• No cross-imports between registry components
• Render/behavior tests in apps/www/tests/data-table.test.tsx (22 tests: sorting, numeric/date sort, multi-sort, grouping, engine selection)

Related issues

Summary by CodeRabbit

• New Features
  • Added global search functionality with debouncing across searchable columns
  • Added multi-column sorting with shift-click support
  • Added row selection with filtered-aware "select all"
  • Added row expansion with custom content rendering
  • Added row grouping with collapsible headers
  • Added per-column freeze (left/right) with improved behavior
  • Added pinned rows and sticky headers
  • Added optional windowed virtualization for large datasets (10k+ rows)
  • Added column grouping for multi-level headers
  • Added feature presets (basic, advanced, enterprise) for simplified configuration

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
uniqueui-platform	Ready	Preview, Comment	Jun 15, 2026 7:50am

[coderabbitai]

📝 Walkthrough

Walkthrough

DataTable is rewritten from a non-generic v1 to a fully typed generic DataTable<T> (v2.0.0). The new component introduces accessor-based column definitions, required getRowId, a preset system, debounced global search, multi-column sorting, row selection/expansion, groupBy with collapsible groups, rowSpan merging, frozen columns with measured widths, pinned rows, sticky headers, and a hand-rolled virtualization engine that auto-switches to a standard engine for rich layout features.

Changes

DataTable v2 rewrite

Layer / File(s)	Summary
Exported types, interfaces, and computeWindow helper registry/data-table/component.tsx, apps/www/components/ui/data-table.tsx	Introduces all new public exports: SortDirection, DataTableSortRule, DataTablePreset, DataTableColumn<T>, DataTableProps<T>, WindowSlice, and the computeWindow virtualization math helper, plus internal sort-type inference and page-size normalization utilities.
Header layout helpers, rowSpan planning, and PRESET_DEFAULTS registry/data-table/component.tsx, apps/www/components/ui/data-table.tsx	Adds flattenColumns, getColumnDepth, buildHeaderRows (computing colSpan/rowSpan for multi-level headers), computeRowSpans for equal-value run merging, and PRESET_DEFAULTS mapping basic/advanced/enterprise to feature flag defaults.
DataTable core: feature resolution, data pipeline, state management registry/data-table/component.tsx, apps/www/components/ui/data-table.tsx	Implements the component body: resolves feature flags from preset+props, emits runtime warnings for incompatible engine combinations, wires debounced search, multi-rule sort with shift-click toggle and type inference, controlled/uncontrolled selection/expansion state, collapsible groupBy, pinned-row separation, and auto engine selection.
Frozen-column width measurement and sticky offset computation registry/data-table/component.tsx, apps/www/components/ui/data-table.tsx	Uses ResizeObserver to measure leaf-column rendered widths, computes cumulative left/right freeze offsets, and derives sticky inline styles (position, offset, z-index, shadow) for header and body cells.
Header and body rendering registry/data-table/component.tsx, apps/www/components/ui/data-table.tsx	Rebuilds renderHeader to emit multi-row header cells with correct colSpan/rowSpan, keyboard-roving sort buttons with aria-sort and multi-sort priority badges, and leading selection/expansion headers. Rebuilds renderBody to handle selectable/expandable rows, rowSpan merging, collapsible group header rows, virtualization spacer rows, and expansion slot rows with measured heights.
Pagination footer: ellipsis strategy, search bar, page navigation registry/data-table/component.tsx, apps/www/components/ui/data-table.tsx	Computes compact pagination items with ellipsis strategy, renders a search input above the table, and wires Previous/Next and page-number buttons to internal currentPage state, removing legacy onPageChange callbacks.
New demo entries and removal of old demo helpers registry/data-table/demo.tsx, registry/demos/shared.tsx, apps/www/config/demos.tsx, registry/demos/demo-key-order.json	Replaces old freeze/bordered/sortable demos with five new typed demos (basic, advanced, virtualized, grouped, column-groups), each exercising different presets and features. Removes withDemoLocation, withDemoFreezeExtras, and related row-enrichment utilities.
Registry metadata, docs scenarios, changelog, and spec registry/components/data-table.json, apps/www/config/components.ts, apps/www/config/docs-scenarios.ts, apps/www/public/registry/..., registry.json, docs/superpowers/specs/2026-06-09-data-table-v2-design.md	Updates all registry JSON entries (description, props schema, variants, usageCode, tags, accessibility, relatedSlugs, changelog 2.0.0), replaces docs-scenarios code snippets with typed v2 examples, and adds the DataTable v2 design spec. Also adjusts unrelated relatedSlugs for dot-grid-background, particle-field, and shooting-stars-grid.
Comprehensive Vitest test suite for DataTable v2 apps/www/tests/data-table.test.tsx	Adds 579 lines of tests covering sort cycling, numeric/date/multi-sort with aria-sort, debounced search, selection/select-all, expandable rows, pagination clamping, virtualization window movement and aria-rowcount, engine switching on groupBy, rowSpan merging, nested column group header spans, preset feature enablement, and computeWindow math.

Sequence Diagram(s)

sequenceDiagram
  participant Consumer
  participant DataTable
  participant DataPipeline
  participant VirtualEngine
  participant StandardEngine

  Consumer->>DataTable: data[], columns[], getRowId, preset, feature props
  DataTable->>DataPipeline: debounce search query → filter rows
  DataPipeline->>DataPipeline: apply multi-sort rules (inferSortType, compareValues)
  DataPipeline->>DataPipeline: separate pinnedRows, paginate
  DataTable->>DataTable: resolve engine (virtualized vs standard)
  alt virtualized engine
    DataTable->>VirtualEngine: computeWindow(scrollTop, viewportHeight, rowHeight, rowCount)
    VirtualEngine-->>DataTable: WindowSlice (start, end, padTop, padBottom)
    DataTable->>DataTable: render spacer rows + visible slice + aria-rowcount/aria-rowindex
  else standard engine (groupBy / rowSpan)
    DataTable->>StandardEngine: groupBy → collapsible group headers
    DataTable->>StandardEngine: computeRowSpans → merged cells
    StandardEngine-->>DataTable: group rows + rowSpan plan
  end
  DataTable->>DataTable: renderHeader (multi-level, frozen offsets, aria-sort)
  DataTable->>DataTable: renderBody (selection, expansion, frozen sticky styles)
  DataTable-->>Consumer: rendered table + pagination footer

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Possibly related PRs

• pras75299/uniqueui#13: Directly touches apps/www/components/ui/data-table.tsx pagination and row-rendering logic, the same file whose pagination controls were restructured in this PR.

Poem

🐇 Hop hop, the table grew wings so tall,
With accessor and getRowId for all!
Two engines hum — virtual or wide,
Shift-click to sort, and rows expand with pride.
The rabbit merged cells and froze columns tight,
computeWindow slices the data just right! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 40.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: rebuilding DataTable as a typed, dual-engine virtualized grid with all key features (typing, dual engines, virtualization).
Description check	✅ Passed	The PR description covers all required template sections: Type (marked), Summary (provided), Test plan (comprehensive), New component checklist (all items addressed), and Related issues.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/data-table-enhance

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 9

🧹 Nitpick comments (1)

registry/data-table/component.tsx (1)

490-515: Move onSort callback outside the state updater.

The function passed to setSortRules must be pure. Invoking onSort?.(next) inside it violates this requirement—React may call the updater function multiple times in Strict Mode, causing duplicate onSort invocations and unpredictable side effects. Calculate next in the pure updater, then invoke onSort in a useEffect hook or at the event handler level.

• registry/data-table/component.tsx#L514: move onSort?.(next) out of the setSortRules((prev) => ...) callback.
• apps/www/components/ui/data-table.tsx#L514: apply the same change.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/component.tsx` around lines 490 - 515, The toggleSort
function in both registry/data-table/component.tsx and
apps/www/components/ui/data-table.tsx calls onSort?.(next) inside the
setSortRules state updater callback, which violates the requirement that state
updaters must be pure functions. This can cause duplicate onSort invocations
when React's Strict Mode calls the updater multiple times. Move the
onSort?.(next) invocation outside of the setSortRules callback and either place
it in a useEffect hook that depends on the sort rules, or invoke it directly in
the toggleSort event handler after the state update. Make this change at both
anchor site (registry/data-table/component.tsx lines 490-515) and sibling site
(apps/www/components/ui/data-table.tsx lines 490-515), ensuring the calculation
of the next sort rules remains pure inside the state updater while the side
effect of calling onSort happens separately.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/www/public/registry/data-table.json`:
- Line 11: The virtual window computation uses flowData (which excludes pinned
rows) to calculate visible row ranges, but the expanded-height compensation
logic checks row indices against rowIdIndex (which maps to sortedData including
all rows), and the aria-rowindex for virtual rendering doesn't account for
pinned rows. Fix this by: (1) adjusting the windowSlice useMemo to track which
rows are pinned when compensating for expanded heights, ensuring the index
checks work against the actual visible data rather than sortedData; (2) updating
the aria-rowindex calculation in the renderDataRow function to add the count of
pinned rows to account for their presence in the DOM; and (3) verifying that the
expanded height tracking and spacer math correctly handle the offset between
flowData indices and the complete row order when pinnedSet.size > 0.

In `@apps/www/tests/data-table.test.tsx`:
- Around line 379-381: The assertion on line 380 that checks for the absence of
"Person 0 " using includes() is fragile because it depends on exact whitespace
formatting in the concatenated cell text. Replace this string-matching approach
with a more semantic assertion that checks for the actual absence of row 0
content using word boundaries or by directly looking up specific cell values by
row identifier or token matching. This ensures the test will reliably fail when
row 0 is actually rendered, regardless of how the text formatting changes.

In `@docs/superpowers/specs/2026-06-09-data-table-v2-design.md`:
- Around line 55-81: The specification document has three alignment issues with
the implemented DataTableProps: First, add the missing sortable?: boolean
property to the feature flags section (after line 55-76) since the component
exposes it. Second, fix the invalid TypeScript shorthand on line 80 by replacing
the shorthand syntax (headerTextColor?, bodyTextColor?, headerBackground?,
bodyBackground?: string) with explicit per-field declarations using proper ?:
string type annotations for each property individually. Third, update the
forced-virtual conflicts documentation (lines 110-112) to also mention that
paginated conflicts with virtualization, not just rowSpan and groupBy.

In `@registry/data-table/component.tsx`:
- Around line 1171-1179: The sort priority indicator is hidden from assistive
technology by the aria-hidden wrapper, making it inaccessible to screen reader
users in multi-sort scenarios. Remove the aria-hidden attribute from the span
wrapper in both files and provide accessible context for the priority number. In
registry/data-table/component.tsx at lines 1171-1179, replace the aria-hidden
wrapper with an accessible solution that exposes the sortPriority value through
an aria-label (such as "sort priority 2") or an sr-only class element containing
descriptive priority text. Mirror the identical change in
apps/www/components/ui/data-table.tsx at lines 1171-1179 to ensure consistency
across both implementations. The directional indicator (↑/↓) may remain visual,
but the priority number must be announced to assistive technology.
- Around line 58-102: The DataTableProps interface is too restrictive and only
exposes className, preventing consumers from passing standard HTML attributes
like id, style, role, aria-*, and data-* to the root wrapper. Extend
DataTableProps to include relevant HTML div properties (such as
React.HTMLAttributes<HTMLDivElement>) while omitting any conflicting event
handlers per coding guidelines, then spread the resulting props onto the root
div element in the component. This pattern should be applied consistently across
all affected locations in the file.
- Around line 755-762: The rowSpanPlans computation is based on visibleRows but
rendering uses group-local indices when groupBy is active, causing row spans to
apply across unrelated rows in different groups. In
registry/data-table/component.tsx#L755-L762 (anchor), modify the useMemo
dependency and computation to use groupedRows instead of visibleRows when
grouping is active, ensuring span plans align with the actual rendered row
order. In registry/data-table/component.tsx#L1272-L1273 (sibling), remove the
group-local index being passed into renderDataRow when accessing the
rowSpanPlans, using the correct global index instead. Apply identical fixes to
the mirrored code in apps/www/components/ui/data-table.tsx at lines 755-762 and
1272-1273 respectively.
- Around line 551-560: The toggleSelectAll callback in both files replaces the
entire selection set, losing selections outside the current filtered set when
searching is active. Modify the toggleSelectAll callback logic in both
registry/data-table/component.tsx (lines 551-560) and
apps/www/components/ui/data-table.tsx (lines 551-560) to preserve existing
selections by deriving the next selection from the current selectedSet and only
adding or removing the filteredIds accordingly. When allFilteredSelected is
true, create a new Set from selectedSet and delete the filteredIds from it; when
false, create a new Set from selectedSet and add the filteredIds to it. Pass
this merged/diffed selection to updateSelection instead of replacing the entire
set.
- Around line 521-525: The rowIdIndex useMemo is currently built from
sortedData, but the virtual window is computed against flowData, causing
coordinate system misalignment when rows are pinned. In
registry/data-table/component.tsx at lines 521-525, change the rowIdIndex to
build from flowData instead of sortedData (or create a separate flowRowIdIndex).
Then in the same file at lines 691-696 where expanded-row spacer adjustment
occurs, update the lookup logic to use the flow-based index map and skip any IDs
that are missing from the map, as those represent pinned rows that should not
adjust virtual spacers. Mirror these exact same changes in
apps/www/components/ui/data-table.tsx at lines 521-525 and 691-696.

In `@registry/data-table/demo.tsx`:
- Around line 52-53: The issue is that the Date object created at lines 52-53
uses local time construction, which when formatted with toISOString() at lines
85-86 will shift to UTC and potentially display the wrong day depending on the
user's timezone. To fix this, change the Date constructor at lines 52-53 from
the local-time Date constructor (new Date(2026, i % 12, (i % 27) + 1)) to use
Date.UTC() to create the date in UTC coordinates, ensuring that when
toISOString() is applied at lines 85-86 for formatting, the displayed date
matches the intended calendar date without timezone shifting.

---

Nitpick comments:
In `@registry/data-table/component.tsx`:
- Around line 490-515: The toggleSort function in both
registry/data-table/component.tsx and apps/www/components/ui/data-table.tsx
calls onSort?.(next) inside the setSortRules state updater callback, which
violates the requirement that state updaters must be pure functions. This can
cause duplicate onSort invocations when React's Strict Mode calls the updater
multiple times. Move the onSort?.(next) invocation outside of the setSortRules
callback and either place it in a useEffect hook that depends on the sort rules,
or invoke it directly in the toggleSort event handler after the state update.
Make this change at both anchor site (registry/data-table/component.tsx lines
490-515) and sibling site (apps/www/components/ui/data-table.tsx lines 490-515),
ensuring the calculation of the next sort rules remains pure inside the state
updater while the side effect of calling onSort happens separately.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9cd5b703-e190-4b8d-8829-f21d05de1521

📥 Commits

Reviewing files that changed from the base of the PR and between c9853a8 and a29fea9.

📒 Files selected for processing (20)

• apps/www/components/ui/data-table.tsx
• apps/www/config/components.ts
• apps/www/config/demos.tsx
• apps/www/config/docs-scenarios.ts
• apps/www/public/r/data-table.json
• apps/www/public/r/registry.json
• apps/www/public/registry.json
• apps/www/public/registry/changelogs.json
• apps/www/public/registry/data-table.json
• apps/www/public/registry/dot-grid-background.json
• apps/www/public/registry/particle-field.json
• apps/www/public/registry/shooting-stars-grid.json
• apps/www/tests/data-table.test.tsx
• docs/superpowers/specs/2026-06-09-data-table-v2-design.md
• registry.json
• registry/components/data-table.json
• registry/data-table/component.tsx
• registry/data-table/demo.tsx
• registry/demos/demo-key-order.json
• registry/demos/shared.tsx

💤 Files with no reviewable changes (1)

• registry/demos/shared.tsx

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Pinned rows break virtual row indexing and expanded spacer math.

Line 11: the virtual window is computed against flowData, but expanded-height compensation uses indices from sortedData, and virtual aria-rowindex is not offset by pinned rows. With pinnedRows, this yields incorrect spacer compensation and incorrect row indices.

Suggested fix direction

- const rowIdIndex = useMemo(() => {
+ const flowRowIndex = useMemo(() => {
    const map = new Map<string, number>();
-   sortedData.forEach((row, i) => map.set(getRowId(row), i));
+   flowData.forEach((row, i) => map.set(getRowId(row), i));
    return map;
- }, [sortedData, getRowId]);
+ }, [flowData, getRowId]);

  // in windowSlice compensation:
- const index = rowIdIndex.get(id);
+ const index = flowRowIndex.get(id);

+ const pinnedCount = pinnedData.length;

  // when rendering pinned rows:
- renderDataRow(row, i, { pinned: true })
+ renderDataRow(row, i, { pinned: true, ariaRowIndex: i + 2 })

  // when rendering virtual flow rows:
- ariaRowIndex: windowSlice.start + i + 2
+ ariaRowIndex: pinnedCount + windowSlice.start + i + 2

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/www/public/registry/data-table.json` at line 11, The virtual window
computation uses flowData (which excludes pinned rows) to calculate visible row
ranges, but the expanded-height compensation logic checks row indices against
rowIdIndex (which maps to sortedData including all rows), and the aria-rowindex
for virtual rendering doesn't account for pinned rows. Fix this by: (1)
adjusting the windowSlice useMemo to track which rows are pinned when
compensating for expanded heights, ensuring the index checks work against the
actual visible data rather than sortedData; (2) updating the aria-rowindex
calculation in the renderDataRow function to add the count of pinned rows to
account for their presence in the DOM; and (3) verifying that the expanded
height tracking and spacer math correctly handle the offset between flowData
indices and the complete row order when pinnedSet.size > 0.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Strengthen the negative scroll assertion to avoid formatting-dependent false positives.

Line 380 checks absence using includes("Person 0 "), which depends on exact whitespace in concatenated cell text. This can pass even when row 0 rendering regresses with different text formatting. Assert semantic absence instead (e.g., word-boundary match on joined text or direct cell lookup by row id/name token).

As per coding guidelines: Write tests that encode WHY behavior matters, not just WHAT it does; ensure tests can fail when business logic changes.

Suggested patch

-    expect(rendered.some((text) => text.includes("Person 0 "))).toBe(false);
+    expect(rendered.join(" ")).not.toMatch(/\bPerson 0\b/);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	expect(rendered.some((text) => text.includes("Person 100"))).toBe(true);
	expect(rendered.some((text) => text.includes("Person 0 "))).toBe(false);
	});
	expect(rendered.some((text) => text.includes("Person 100"))).toBe(true);
	expect(rendered.join(" ")).not.toMatch(/\bPerson 0\b/);
	});

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/www/tests/data-table.test.tsx` around lines 379 - 381, The assertion on
line 380 that checks for the absence of "Person 0 " using includes() is fragile
because it depends on exact whitespace formatting in the concatenated cell text.
Replace this string-matching approach with a more semantic assertion that checks
for the actual absence of row 0 content using word boundaries or by directly
looking up specific cell values by row identifier or token matching. This
ensures the test will reliably fail when row 0 is actually rendered, regardless
of how the text formatting changes.

Source: Coding guidelines

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Align the spec API snippet with the implemented DataTableProps contract.

There are a few contract drifts:

• Line 55-Line 76 omits sortable?: boolean even though the component type exposes it.
• Line 80 uses invalid TS shorthand (headerTextColor?, ...?: string) instead of per-field ?: string.
• Line 110-Line 112 mentions forced-virtual conflicts for rowSpan/groupBy, but runtime logic also treats paginated as conflicting.

Also applies to: 109-112

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/superpowers/specs/2026-06-09-data-table-v2-design.md` around lines 55 -
81, The specification document has three alignment issues with the implemented
DataTableProps: First, add the missing sortable?: boolean property to the
feature flags section (after line 55-76) since the component exposes it. Second,
fix the invalid TypeScript shorthand on line 80 by replacing the shorthand
syntax (headerTextColor?, bodyTextColor?, headerBackground?, bodyBackground?:
string) with explicit per-field declarations using proper ?: string type
annotations for each property individually. Third, update the forced-virtual
conflicts documentation (lines 110-112) to also mention that paginated conflicts
with virtualization, not just rowSpan and groupBy.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Extend and forward root <div> props.

DataTableProps only exposes className, so registry consumers cannot pass root id, style, role, aria-*, or data-* attributes to the wrapper rendered below. Extend the relevant div props and spread the rest onto the root.

♻️ Proposed patch

-export interface DataTableProps<T> {
+export interface DataTableProps<T>
+  extends Omit<React.HTMLAttributes<HTMLDivElement>, "children"> {
   data: T[];
   columns: DataTableColumn<T>[];
   /** Stable row id — selection, expansion, pinning, and windowing keys. */
   getRowId: (row: T) => string;
@@
   headerBackground?: string;
   bodyBackground?: string;
-  className?: string;
 }
@@
   headerBackground,
   bodyBackground,
   className,
+  ...rootProps
 }: DataTableProps<T>) {
@@
     <div
+      {...rootProps}
       className={cn("w-full rounded-lg", className)}
       data-engine={virtual ? "virtual" : "standard"}
     >

As per coding guidelines, registry/**/*.tsx: "Extend the relevant HTML/motion props interface and omit conflicting event handlers in TypeScript components."

Also applies to: 1302-1305

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/component.tsx` around lines 58 - 102, The DataTableProps
interface is too restrictive and only exposes className, preventing consumers
from passing standard HTML attributes like id, style, role, aria-*, and data-*
to the root wrapper. Extend DataTableProps to include relevant HTML div
properties (such as React.HTMLAttributes<HTMLDivElement>) while omitting any
conflicting event handlers per coding guidelines, then spread the resulting
props onto the root div element in the component. This pattern should be applied
consistently across all affected locations in the file.

Source: Coding guidelines

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use flow-row indexes for virtual expansion spacer math.

The virtual window is computed against flowData, but expanded-row spacer adjustment reads indices from sortedData. Once rows are pinned, those coordinate systems diverge; pinned expanded rows can also be counted even though they sit outside the virtual flow.

• registry/data-table/component.tsx#L521-L525: build the index map from flowData after pinned rows are split out, or add a separate flowRowIdIndex.
• registry/data-table/component.tsx#L691-L696: look up expanded IDs in the flow map; missing IDs are pinned and should not adjust virtual spacers.
• apps/www/components/ui/data-table.tsx#L521-L525: mirror the same flow-based index map.
• apps/www/components/ui/data-table.tsx#L691-L696: mirror the same flow-map lookup.

🐛 Suggested direction

-  const rowIdIndex = useMemo(() => {
-    const map = new Map<string, number>();
-    sortedData.forEach((row, i) => map.set(getRowId(row), i));
-    return map;
-  }, [sortedData, getRowId]);
+  // Define after `flowData` is computed.
+  const flowRowIdIndex = useMemo(() => {
+    const map = new Map<string, number>();
+    flowData.forEach((row, i) => map.set(getRowId(row), i));
+    return map;
+  }, [flowData, getRowId]);
@@
-      const index = rowIdIndex.get(id);
+      const index = flowRowIdIndex.get(id);
       if (index === undefined) continue;
@@
-    rowIdIndex,
+    flowRowIdIndex,

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const rowIdIndex = useMemo(() => {
	const map = new Map<string, number>();
	sortedData.forEach((row, i) => map.set(getRowId(row), i));
	return map;
	}, [sortedData, getRowId]);
	const flowRowIdIndex = useMemo(() => {
	const map = new Map<string, number>();
	flowData.forEach((row, i) => map.set(getRowId(row), i));
	return map;
	}, [flowData, getRowId]);

📍 Affects 2 files

• registry/data-table/component.tsx#L521-L525 (this comment)
• registry/data-table/component.tsx#L691-L696
• apps/www/components/ui/data-table.tsx#L521-L525
• apps/www/components/ui/data-table.tsx#L691-L696

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/component.tsx` around lines 521 - 525, The rowIdIndex
useMemo is currently built from sortedData, but the virtual window is computed
against flowData, causing coordinate system misalignment when rows are pinned.
In registry/data-table/component.tsx at lines 521-525, change the rowIdIndex to
build from flowData instead of sortedData (or create a separate flowRowIdIndex).
Then in the same file at lines 691-696 where expanded-row spacer adjustment
occurs, update the lookup logic to use the flow-based index map and skip any IDs
that are missing from the map, as those represent pinned rows that should not
adjust virtual spacers. Mirror these exact same changes in
apps/www/components/ui/data-table.tsx at lines 521-525 and 691-696.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Preserve selections outside the current filtered set.

The shared root cause is replacing the whole selection set when toggling the header checkbox. With an active search, this drops IDs that were already selected but are not in filteredIds, and onSelectionChange receives a truncated selection.

• registry/data-table/component.tsx#L551-L560: derive next from selectedSet, then add/delete only the current filteredIds.
• apps/www/components/ui/data-table.tsx#L551-L560: mirror the same merge/diff behavior.

🐛 Proposed patch for both files

   const toggleSelectAll = useCallback(() => {
-    updateSelection(allFilteredSelected ? new Set() : new Set(filteredIds));
-  }, [allFilteredSelected, filteredIds, updateSelection]);
+    const next = new Set(selectedSet);
+    if (allFilteredSelected) {
+      filteredIds.forEach((id) => next.delete(id));
+    } else {
+      filteredIds.forEach((id) => next.add(id));
+    }
+    updateSelection(next);
+  }, [allFilteredSelected, filteredIds, selectedSet, updateSelection]);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const filteredIds = useMemo(
	() => sortedData.map((row) => getRowId(row)),
	[sortedData, getRowId]
	);
	const allFilteredSelected =
	filteredIds.length > 0 && filteredIds.every((id) => selectedSet.has(id));
	const someFilteredSelected = filteredIds.some((id) => selectedSet.has(id));
	const toggleSelectAll = useCallback(() => {
	updateSelection(allFilteredSelected ? new Set() : new Set(filteredIds));
	}, [allFilteredSelected, filteredIds, updateSelection]);
	const filteredIds = useMemo(
	() => sortedData.map((row) => getRowId(row)),
	[sortedData, getRowId]
	);
	const allFilteredSelected =
	filteredIds.length > 0 && filteredIds.every((id) => selectedSet.has(id));
	const someFilteredSelected = filteredIds.some((id) => selectedSet.has(id));
	const toggleSelectAll = useCallback(() => {
	const next = new Set(selectedSet);
	if (allFilteredSelected) {
	filteredIds.forEach((id) => next.delete(id));
	} else {
	filteredIds.forEach((id) => next.add(id));
	}
	updateSelection(next);
	}, [allFilteredSelected, filteredIds, selectedSet, updateSelection]);

📍 Affects 2 files

• registry/data-table/component.tsx#L551-L560 (this comment)
• apps/www/components/ui/data-table.tsx#L551-L560

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/component.tsx` around lines 551 - 560, The
toggleSelectAll callback in both files replaces the entire selection set, losing
selections outside the current filtered set when searching is active. Modify the
toggleSelectAll callback logic in both registry/data-table/component.tsx (lines
551-560) and apps/www/components/ui/data-table.tsx (lines 551-560) to preserve
existing selections by deriving the next selection from the current selectedSet
and only adding or removing the filteredIds accordingly. When
allFilteredSelected is true, create a new Set from selectedSet and delete the
filteredIds from it; when false, create a new Set from selectedSet and add the
filteredIds to it. Pass this merged/diffed selection to updateSelection instead
of replacing the entire set.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Compute row spans in the grouped display order.

rowSpanPlans is generated for visibleRows, then grouped rendering re-buckets rows and passes a group-local i into renderDataRow. Combining groupBy and rowSpan can therefore apply spans from unrelated rows and render malformed merged cells.

• registry/data-table/component.tsx#L755-L762: compute span plans against the rows as rendered, e.g. per group when groupedRows is active.
• registry/data-table/component.tsx#L1272-L1273: do not pass a group-local index into a plan generated for the full visibleRows array.
• apps/www/components/ui/data-table.tsx#L755-L762: mirror the grouped-order span computation.
• apps/www/components/ui/data-table.tsx#L1272-L1273: mirror the grouped render index fix.

📍 Affects 2 files

• registry/data-table/component.tsx#L755-L762 (this comment)
• registry/data-table/component.tsx#L1272-L1273
• apps/www/components/ui/data-table.tsx#L755-L762
• apps/www/components/ui/data-table.tsx#L1272-L1273

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/component.tsx` around lines 755 - 762, The rowSpanPlans
computation is based on visibleRows but rendering uses group-local indices when
groupBy is active, causing row spans to apply across unrelated rows in different
groups. In registry/data-table/component.tsx#L755-L762 (anchor), modify the
useMemo dependency and computation to use groupedRows instead of visibleRows
when grouping is active, ensuring span plans align with the actual rendered row
order. In registry/data-table/component.tsx#L1272-L1273 (sibling), remove the
group-local index being passed into renderDataRow when accessing the
rowSpanPlans, using the correct global index instead. Apply identical fixes to
the mirrored code in apps/www/components/ui/data-table.tsx at lines 755-762 and
1272-1273 respectively.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Expose multi-sort priority to assistive tech.

The only priority indicator is inside an aria-hidden wrapper, while aria-sort only exposes direction. Screen-reader users cannot determine first/second/etc. sort priority in multi-sort mode.

• registry/data-table/component.tsx#L1171-L1179: remove aria-hidden from the wrapper and expose the priority with contextual text, such as aria-label="sort priority 2" or an sr-only label.
• apps/www/components/ui/data-table.tsx#L1171-L1179: mirror the same accessible priority label.

As per coding guidelines, **/*.{tsx,jsx}: "a11y notes must not hide content: Never advise aria-hidden on wrappers that contain readable children; restrict to decorative layers only."

📍 Affects 2 files

• registry/data-table/component.tsx#L1171-L1179 (this comment)
• apps/www/components/ui/data-table.tsx#L1171-L1179

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/component.tsx` around lines 1171 - 1179, The sort
priority indicator is hidden from assistive technology by the aria-hidden
wrapper, making it inaccessible to screen reader users in multi-sort scenarios.
Remove the aria-hidden attribute from the span wrapper in both files and provide
accessible context for the priority number. In registry/data-table/component.tsx
at lines 1171-1179, replace the aria-hidden wrapper with an accessible solution
that exposes the sortPriority value through an aria-label (such as "sort
priority 2") or an sr-only class element containing descriptive priority text.
Mirror the identical change in apps/www/components/ui/data-table.tsx at lines
1171-1179 to ensure consistency across both implementations. The directional
indicator (↑/↓) may remain visual, but the priority number must be announced to
assistive technology.

Source: Coding guidelines

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Avoid UTC-shifting calendar dates in the advanced demo.

Line 52 creates a local-time Date, but Line 85 formats it with toISOString(), which can display the previous/next day depending on timezone.

💡 Suggested fix

+    const formatDate = (d: Date) =>
+      `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
+
     const rows = Array.from({ length: 24 }, (_, i) => ({
       id: `ord-${i + 1}`,
       order: `#${String(2400 + i)}`,
       customer: ["Alex Kim", "Sara Chen", "Jordan Lee", "Maya Patel", "Ryan Wu", "Priya Shah"][i % 6],
       total: Math.round((i * 53.7 + 24) * 100) / 100,
       status: ["Paid", "Pending", "Refunded"][i % 3],
       placed: new Date(2026, i % 12, (i % 27) + 1),
     }));
@@
             {
               id: "placed",
               header: "Placed",
               accessor: (row: Row) => row.placed,
-              cell: (row: Row) => row.placed.toISOString().slice(0, 10),
+              cell: (row: Row) => formatDate(row.placed),
             },

Also applies to: 85-86

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@registry/data-table/demo.tsx` around lines 52 - 53, The issue is that the
Date object created at lines 52-53 uses local time construction, which when
formatted with toISOString() at lines 85-86 will shift to UTC and potentially
display the wrong day depending on the user's timezone. To fix this, change the
Date constructor at lines 52-53 from the local-time Date constructor (new
Date(2026, i % 12, (i % 27) + 1)) to use Date.UTC() to create the date in UTC
coordinates, ensuring that when toISOString() is applied at lines 85-86 for
formatting, the displayed date matches the intended calendar date without
timezone shifting.