`.** When a component accepts a `className`, prefer it to wrapping the render result in a styled `
`. Wrapping changes the DOM structure and breaks layout assumptions in many table, grid, and list contexts; using `className` keeps the wrapping consistent with non-example usage.\n- **Use the wrapper component the project ships.** If the project ships a shadcn-style wrapper (`DataTableCell`, `DataTableColumn`), use it in examples instead of the unwrapped primitive. The wrapped form is what users will copy; show that path.\n- **Skip the JSX import boilerplate in snippets.** Inline code blocks in the middle of prose are clearer when they show only the JSX under discussion. Save the full `import` list for live blocks that need to run.\n","isInternal":false,"tokens":827,"sizeBytes":4072},{"name":"page-shapes.md","path":".codex/skills/docs-guidance/references/page-shapes.md","rawUrl":"https://raw.githubusercontent.com/petyosi/react-virtuoso/HEAD/.codex/skills/docs-guidance/references/page-shapes.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Page Shapes and Section Shapes\n\nTemplates for whole pages (by type) and for recurring section shapes within pages.\n\nConsult this file when writing a new page from scratch, restructuring an existing page, or naming/ordering the sections of a page that already has its content roughed in.\n\n## Page Shapes by Type\n\n### Concept pages\n\nFor pages that introduce a single concept or primitive (a model, a hook, a low-level component). The audience is developers learning the primitive itself.\n\nIf the page describes a feature with a user-facing surface — grouping, filtering, drag-and-drop, sticky pinning, column reorder, visibility toggles — use the **Feature pages** template instead. Concept template is for pure-developer-facing primitives.\n\n- Open with the reader problem.\n- Explain the concept in ordinary words.\n- Show the data/state/API contract.\n- Show the smallest safe example.\n- Add runtime/lifecycle caveats.\n- Link to one deeper example or adjacent decision.\n\n### Feature pages\n\nFor pages that describe a user-facing capability — grouped rows, filtering, sorting, column reorder, column visibility, sticky pinning, drag-and-drop, expand/collapse. The developer reading the page is configuring something their end user will see or interact with.\n\nThe temptation in feature docs is to lead with the data shape or config object because it's the cleanest thing the writer understands. Resist it — the data shape is what makes the feature work, not what makes the feature interesting to the reader.\n\n- **What the end user sees.** Open with a sentence (or a small \"this is the result\" demo) describing the visible outcome.\n- **What the end user does.** If the feature is interactive, demonstrate the interaction with a live example that includes the UI control the user clicks, toggles, or drags. Static-only demos of interactive features are a smell — see [diagnostics.md](diagnostics.md#feature-pages).\n- **How to wire the interaction.** The API surface that exposes the behavior (model action, hook, prop) paired with the UI piece that triggers it. Treat the UI and the model wiring as one recipe; splitting them hides the half the reader came for.\n- **The data contract or config shape.** Only after the interaction has been shown. The contract is in service of the recipe above it.\n- **Variations.** Local vs remote, simple vs interactive, single-level vs multi-level — each as a sub-section that re-uses the user-behavior-first ordering.\n- **Limits and escape hatches.** Close with what doesn't fit and where to go next.\n\n### Example pages\n\nFor pages that demonstrate a recipe end-to-end.\n\n- First paragraph: \"This example uses X to solve Y.\"\n- `## APIs used` — short list grouped by job, not exhaustive reference.\n- Runnable example code.\n- Closing section named `## Notes`, `## When this doesn't fit`, `## When to outgrow this shape`, or `## What this leaves out`.\n\n### Troubleshooting and performance pages\n\n- Lead with symptoms and decision rules.\n- Prefer tables mapping symptom → fix.\n- Avoid implying users should tune defaults without a concrete symptom.\n\n### Installation pages\n\n- State what gets installed or generated.\n- Distinguish local editable code from package dependencies.\n- Show the smallest successful setup.\n- Link to the next required setup tasks.\n\n### Migration pages\n\n- State what is not a drop-in replacement.\n- Map old concepts to new concepts.\n- Give a recommended sequence, not a pile of independent facts.\n- End with the core mental-model shift.\n\n## Section Shapes (within pages)\n\nThese shapes recur across multiple page types — use them wherever they fit.\n\n### Limitation-focused section (gotcha-led)\n\nWhen a section exists because of a trap — \"Placeholders\" in a runtime-discovery page, \"Empty responses\" in a remote-data page, \"Schema drift\" in a persistence page:\n\n1. Open with the trap. Describe the bug the section's recipe prevents.\n2. Show the recipe.\n3. Add sidebar advice for cases the recipe still doesn't cover.\n\nExample opening: _\"The field scanner has no way to tell offset-mode placeholders apart from real rows — it treats them as ordinary data.\"_ — then the schema-compatible placeholder recipe.\n\n### Comparison / \"When this does not fit\" section\n\nWhen enumerating alternatives at the end of a page, use **named bullets** with bold term labels:\n\n```markdown\n- **Backend-defined schemas.** Use when the backend already knows the shape.\n- **Statically-known schemas.** Use when the schema is in code but the JSX would be repetitive.\n- **Runtime column-management UI.** Lift the field list into your own state when the user can add or reorder fields after mount.\n```\n\nClose with a one-sentence summary of when the current page's approach _does_ fit.\n\n### Topic-first, alternative-second\n\nNever open a section by recommending the alternative it is meant to compare against. Pattern:\n\n1. Show the section's actual topic.\n2. After the example, add a sidebar paragraph for the alternative — \"When the backend can return column metadata alongside the rows, prefer that.\"\n\n### Parameter / config explanation block\n\nWhen showing what arrives at a render prop, hook, or callback, use bullets per parameter:\n\n```markdown\nThe render function is called with `{ data, model }`:\n\n- `data` is X — it does not change when Y.\n- `model` is Z — available for the rare case where W.\n```\n\nEasier to scan than parallel prose sentences.\n\n### \"How the contract looks\" before the example\n\nWhen behavior depends on a contract (data shape, config shape, event payload), render the shape inline before the runnable example:\n\n````markdown\nThe render function receives:\n\n```ts\n{\n data: readonly Row[]\n model: DataModelHandle
\n}\n```\n\nThen the example…\n````\n\nThe shape grounds the example. Without it, the reader has to reverse-engineer the contract from the example body.\n","isInternal":false,"tokens":1236,"sizeBytes":5833},{"name":"SKILL.md","path":".codex/skills/docs-guidance/SKILL.md","rawUrl":"https://raw.githubusercontent.com/petyosi/react-virtuoso/HEAD/.codex/skills/docs-guidance/SKILL.md","title":"docs-guidance","category":"anthropic-skill","format":"markdown","content":"---\nname: docs-guidance\ndescription: Revises project documentation for human readability, conceptual flow, and example safety. Covers concept pages, example pages, troubleshooting, installation, and migration docs. Use when writing or reviewing docs, when the user says a page \"feels off\", \"feels weird\", \"feels sudden\", or \"needs attention\", when asked to make a doc clearer or to rewrite a section, when fixing cold or abrupt openings, when a section opens with the API mechanism instead of the user's problem, or when comparing prose against a readability standard.\n---\n\n# Docs Guidance\n\nUse this skill for project documentation work. Treat docs quality as a product concern: the reader should understand where they are, why the topic exists, what shape the relevant data or API has, and when the shown pattern stops fitting.\n\nThis skill is intentionally general. Apply it to package docs, guides, examples, troubleshooting pages, migration notes, and installation pages across the repo.\n\n## Workflow\n\n1. Start from the reader's task, decision, or confusion, not from the API list.\n2. Identify the core contract the page must teach: state ownership, data shape, lifecycle, render boundary, persistence keying, configuration shape, backend shape, or control surface.\n3. Rewrite around the path: user problem → concept → contract → runnable example → limits and next step.\n4. Keep examples safe for real usage, not just short.\n5. End with a concrete escape hatch: where to go when this example no longer fits.\n\n## Core Readability Rules\n\nThese are the non-negotiables. Most doc-quality problems trace to violating one of them:\n\n- **Start from the reader's situation.** Open each page with the user problem, decision, or concrete setup. Never begin with an unexplained abstraction or API name unless the page is explicit API reference.\n- **Describe, don't dramatize.** State what the thing is and what it does in literal terms. Don't open with what users feel or expect (\"users expect…\", \"users develop opinions about…\"); don't give code or UI intentions, conflicts, or effort (\"the slot fights for space\", \"the header expects to do work\"); don't enumerate capabilities as atmospheric color when the page only covers some of them. Narrative motivation, anthropomorphism, and vibes lists all signal the writer didn't commit to a direct statement of the mechanism. See [diagnostics.md → Framing tone](references/diagnostics.md#framing-tone) for the specific smells.\n- **Define concepts before using them.** Don't introduce project terms (`engine`, `slot`, `pipeline`, `marker`, `adapter`, `state cell`, `registry`, `provider`) without grounding them in the user's mental model first.\n- **Explain why before how.** Show the pressure that creates the API — rows need stable identity, requests can be superseded, persisted state needs a stable key — before showing the call signature.\n- **For feature pages, lead with user-facing behavior.** If a feature has an end-user surface (something the user sees, clicks, drags, toggles), demonstrate that surface — visibly, interactively when it's interactive — before the developer-facing config or data contract. The developer is reading the page to enable an end-user behavior; the end-user behavior is the topic, not the config that supports it.\n- **Show the contract just before the recipe it grounds.** When you're about to drop a code block whose behavior depends on a contract, render the data/state/config shape one paragraph before the code so the example doesn't have to be reverse-engineered. This is a within-section pattern, not a whole-page ordering rule — at page level, the user-facing behavior (for feature pages) or the reader's problem (for concept pages) comes first.\n- **End with a concrete next step.** Every section should exit with a pointer to the next decision, deeper example, or escape hatch.\n\n## When to consult deeper material\n\nLoad these references when the work calls for them. Keeping them out of this file is deliberate — load only what the current task needs.\n\n- **[references/diagnostics.md](references/diagnostics.md)** — the invariants framework (what every page must teach) and the failure smells (what to look for when reviewing). Consult when reviewing, diagnosing, or auditing existing prose.\n- **[references/page-shapes.md](references/page-shapes.md)** — templates for concept, example, troubleshooting, installation, migration, and limitation-focused pages, plus templates for section-level shapes (gotcha-led, comparison, topic-first-alternative-second). Consult when writing a new page or restructuring an existing one.\n- **[references/example-craft.md](references/example-craft.md)** — rules for the code examples themselves: stable instances, variable-shape demo data, identifier conflict resolution, defensive-to-positive framing, and styling-layer choices. Consult when writing or auditing example code blocks.\n\n## Final Check\n\nBefore finishing, confirm:\n\n- Can a reader understand the first paragraph without reading another page?\n- Are all public terms introduced before use?\n- Does every code example model safe state ownership and lifecycle?\n- Does every advanced mechanism explain the user pressure that creates it?\n- Does the page tell the reader what to do next when this pattern is not enough?\n","frontmatter":{"name":"docs-guidance","description":"Revises project documentation for human readability, conceptual flow, and example safety. Covers concept pages, example pages, troubleshooting, installation, and migration docs. Use when writing or reviewing docs, when the user says a page \"feels off\", \"feels weird\", \"feels sudden\", or \"needs attention\", when asked to make a doc clearer or to rewrite a section, when fixing cold or abrupt openings, when a section opens with the API mechanism instead of the user's problem, or when comparing prose against a readability standard."},"isInternal":false,"tokens":1089,"sizeBytes":5322},{"name":"CLAUDE.md","path":"packages/data-table/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/petyosi/react-virtuoso/HEAD/packages/data-table/CLAUDE.md","title":"Data-table Skill","category":"anthropic-skill","format":"markdown","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Development Commands\n\n- `pnpm build` - Build the library using TypeScript compiler and Vite\n- `pnpm lint` - Run linting with oxlint (type-aware)\n- `pnpm typecheck` - Run TypeScript type checking without emitting files\n- `pnpm test` - Run tests with Vitest (node and browser projects)\n- `pnpm dev` - Start Ladle development server for component stories\n- `pnpm docs:build` - Generate TypeDoc documentation\n- `pnpm docs:serve` - Serve generated documentation\n- `pnpm format` - Format code with oxfmt\n- `pnpm format:check` - Check formatting without modifying files\n\n## After Making Changes\n\nRun these commands after modifying code:\n\n1. `pnpm format` - Format modified files\n2. `pnpm lint` - Check for lint errors and fix any issues\n3. `pnpm typecheck` - Verify no TypeScript errors\n4. `pnpm test` - Run tests when changes affect component logic, state management, or virtualization behavior\n\nGit hooks (via Lefthook) automatically run formatting and linting on pre-commit, and typecheck + tests on pre-push.\n\n## Architecture Overview\n\nThis is a React virtualized data table component with both column and row virtualization. The architecture is based on a reactive state management system using `@virtuoso.dev/reactive-engine`.\n\n### Core Components\n\n- **VirtuosoDataTable** (`src/VirtuosoDataTable.tsx`) - Main React component that renders the virtualized data table\n- **VirtualizedTableContent** (`src/VirtualizedTableContent.tsx`) - Renders the table content with row and column virtualization\n- **Row** (`src/Row.tsx`) - Individual row renderer\n- **Column** (`src/Column.tsx`) - Column renderer with virtualization\n- **Cell** (`src/Cell.tsx`) - Cell renderer\n- **ColumnHeader** (`src/ColumnHeader.tsx`) - Column header renderer\n- **Data State** (`src/data.ts`) - Holds data cells (`data$`, `context$`, `totalCount$`)\n\n### State Management Architecture\n\nThe component uses a realm-based reactive system with cells:\n\n- **Cells** - Hold state values (e.g., `data$`, `context$`, `totalCount$`)\n- **Realm** - Manages the reactive graph and subscriptions\n\nKey state modules:\n\n- `src/data.ts` - Core data cells\n- `src/dom.ts` - DOM measurements and scroll handling\n- `src/row-state.ts` - Row rendering state management and visible row computation\n- `src/column-state.ts` - Column virtualization state\n- `src/sizes.ts` - Size tree management for virtualization\n- `src/state-flags.ts` - Scroll direction and bottom detection\n\n### Virtualization System\n\n- **Size Tree** (`src/sizing/AATree.ts`) - AA tree implementation for efficient size tracking\n- **Offset Calculations** (`src/sizing/` directory) - Handles item positioning and measurements\n- **Resize Observer** - Tracks item size changes dynamically\n- **Viewport Management** - Renders only visible items with buffer zones\n\n### Scroll Behavior Management\n\n- **Scroll-to-Row** (`src/scroll-to-row.ts`) - Handles programmatic scrolling to specific rows\n- **Smooth Scrolling** (`src/useSmoothScroll.ts`) - Custom smooth scroll implementation\n- **Mobile Safari Fixes** (`src/reverse-scroll-fix.ts`) - Platform-specific scroll behavior corrections\n\n### Testing Infrastructure\n\nTests are organized into two Vitest projects:\n\n- **Node Tests** - Pure logic tests in `tests/node/` and `src/sizing/tests/node/`\n- **Browser Tests** - Component tests using Playwright browser in `tests/browser/` and `src/tests/browser/`\n - Setup file: `src/tests/browser/setup.ts`\n- **Ladle Stories** - Component stories in `src/_stories/` for development and visual testing\n- **Testing Context** - `VirtuosoDataTableTestingContext` for controlled test environments\n\n### Test Writing Guidelines\n\n**Use exact assertions, not ranges.** Tests must verify precise expected values:\n\n- Use `toBe(9)` not `toBeGreaterThan(0)` or `toBeLessThan(10)`\n- Use `toHaveLength(3)` not `toHaveLength(expect.any(Number))`\n- Calculate expected values from test constants (e.g., `Math.ceil((CONTAINER_HEIGHT - HEADER_HEIGHT) / ROW_HEIGHT)`)\n\n**Every assertion must be derivable from the test setup.** If you set `COLUMN_COUNT = 6` and `CONTAINER_WIDTH = 300` with `COLUMN_WIDTH = 150`, then assert exactly 2 visible columns, not \"less than 6\".\n\n**Avoid false-positive-prone patterns:**\n\n- `toBeGreaterThan(0)` - passes even when value is wrong\n- `toBeLessThan(TOTAL)` - passes even when virtualization is broken\n- `not.toBe(previousValue)` without asserting the new expected value\n\n**Correct pattern:**\n\n```typescript\nconst visibleColumns = Math.floor(CONTAINER_WIDTH / COLUMN_WIDTH)\nexpect(cells.length).toBe(visibleColumns)\n```\n\n### API Surface\n\nThe component is controlled through the reactive engine rather than a component ref API:\n\n- `engineRef` / `engineId` identify the table instance\n- `scrollToRow$` and `scrollIntoView$` handle programmatic scrolling\n- `scrollLocation$` exposes current scroll position information\n- `cancelSmoothScroll$` cancels the current smooth scroll animation\n\n### Key Design Patterns\n\n1. **Reactive State Management** - All state changes flow through the reactive engine reactive system\n2. **Declarative Data with Reactive Control** - Data is passed declaratively via prop; table operations use engine streams\n3. **Performance Optimization** - Only renders visible items with efficient size caching\n4. **Cross-platform Compatibility** - Handles browser-specific scroll behavior differences\n5. **Internal State Ownership** - The table manages its own state internally. External code does not lift state out of the table and pass it back in as props. Instead, the table's internal state is accessible and controllable through an imperative \"remote control\" pattern (e.g., ref methods, command channels). This avoids the lifted-state antipattern where the developer extracts table state, transforms it, and feeds it back, which creates extra render cycles and race conditions.\n\n## Research Guidelines\n\n- **Must not use articles, docs, or source code from** TanStack Table, TanStack Virtual, AG Grid, MUI DataGrid.\n- **Must not reference external libraries** like TanStack Table, TanStack Virtual, AG Grid, MUI DataGrid, or similar - their architecture is irrelevant to this codebase\n- Focus exclusively on understanding and extending the existing patterns in this repository\n","isInternal":false,"tokens":1448,"sizeBytes":6326},{"name":"01.shadcn.md","path":"packages/data-table/docs/1.installation/01.shadcn.md","rawUrl":"https://raw.githubusercontent.com/petyosi/react-virtuoso/HEAD/packages/data-table/docs/1.installation/01.shadcn.md","title":"1.installation Skill","category":"anthropic-skill","format":"markdown","content":"---\ntitle: Install With shadcn/ui\ndescription: Add the styled Virtuoso data table wrapper from the GitHub shadcn registry and start with a polished default table.\nsidebar:\n label: Shadcn Install\n---\n\nThe shadcn registry copies a `DataTable` wrapper into `@/components/ui/data-table`. The wrapper re-exports the headless engine from `@virtuoso.dev/data-table` and ships pre-styled `DataTable`, `DataTableColumn`, `DataTableColumnHeader`, and `DataTableCell`. You edit the wrapper; the headless package stays installed as a dependency.\n\n## Prerequisites\n\n- A React application with TypeScript\n- Tailwind CSS configured\n- shadcn/ui initialized in the project\n- Path aliases resolvable from the root config shadcn reads. If a project uses a solution-style root `tsconfig.json` that only contains `references`, mirror the `@/*` path mapping there or shadcn may create a literal `@/components/...` directory instead of writing into `src/components/...`.\n\n## Add the registry component\n\n```bash\nnpx shadcn@latest add petyosi/react-virtuoso/data-table\n```\n\nThe command writes the wrapper to `@/components/ui/data-table` and imports `@virtuoso.dev/data-table/styles.css` (structural layout defaults). No extra CSS setup is needed.\n\nFeature-specific wrapper components use the same GitHub registry address. For example, add the resize handle when you enable column resizing:\n\n```bash\nnpx shadcn@latest add petyosi/react-virtuoso/data-table-resize-handle\n```\n\nAdd the sort header button when sortable column headers should dispatch model actions:\n\n```bash\nnpx shadcn@latest add petyosi/react-virtuoso/data-table-sort-header-button\n```\n\nThe hosted registry URL still works if you prefer the existing virtuoso.dev registry endpoint:\n\n```bash\nnpx shadcn@latest add https://virtuoso.dev/r/data-table.json\n```\n\n## Icon library\n\nThe wrapper uses [`lucide-react`](https://lucide.dev/) for the loading spinner, error icon, drag grip, and sort button icons. The `npx shadcn add` command installs `lucide-react` as a dependency on first run.\n\nshadcn's `iconLibrary` field in `components.json` only rewrites icon imports for the canonical shadcn registry — it does not touch components from third-party registries like ours. If your project uses a different icon set (`@radix-ui/react-icons`, `phosphor-react`, etc.) and you want the table icons to match, open the installed files under `@/components/ui/data-table` and swap the lucide imports for your library's equivalents. The icons appear in:\n\n- `index.tsx` — `Loader2` (spinner), `AlertCircle` (error state)\n- `column-reorder/reorder-grip.tsx` — `GripVertical` (drag handle)\n- `column-sort/sort-header-button.tsx` — `ArrowUpDown`, `ArrowUp`, `ArrowDown` (sort state)\n\n## Basic styled table\n\n```tsx live wide file=App.tsx\nimport { DataTable, DataTableCell, DataTableColumn, DataTableColumnHeader } from '@/components/ui/data-table'\n\nimport { products } from './data'\nimport { localModel } from '@virtuoso.dev/data-table'\n\nconst currency = new Intl.NumberFormat('en-US', {\n currency: 'USD',\n style: 'currency',\n})\n\nconst model = localModel({ data: products })\n\nexport default function App() {\n return (\n \n \n Product\n {({ cellValue }) => String(cellValue)}\n \n \n Category\n {({ cellValue }) => String(cellValue)}\n \n \n Price\n {({ cellValue }) => currency.format(Number(cellValue))}\n \n \n Stock\n {({ cellValue }) => String(cellValue)}\n \n \n )\n}\n```\n\n```ts live file=data.ts\nexport interface Product {\n id: string\n name: string\n category: 'Audio' | 'Office' | 'Peripherals'\n price: number\n stock: number\n}\n\nexport const products: Product[] = [\n { id: 'SKU-001', name: 'Standing Desk', category: 'Office', price: 699, stock: 14 },\n { id: 'SKU-002', name: 'USB-C Dock', category: 'Peripherals', price: 229, stock: 42 },\n { id: 'SKU-003', name: 'Mechanical Keyboard', category: 'Peripherals', price: 169, stock: 28 },\n { id: 'SKU-004', name: 'Noise-canceling Headset', category: 'Audio', price: 319, stock: 9 },\n]\n```\n\n## Next steps\n\nThe wrapper picks up your shadcn theme automatically (border radius, color tokens, typography). Edit `@/components/ui/data-table` directly for custom row hover states, sticky backgrounds, or denser spacing.\n\nThe two required setup steps after installation are [data model](/data-table/data-model/) and\n[columns](/data-table/columns/). For an inventory of what `npx shadcn add` actually wrote into\nyour project and how to edit it, see [The shadcn Wrapper](/data-table/customization/shadcn-wrapper/);\nfor per-instance visual changes, see [Styling](/data-table/customization/styling/).\n\nRemote models, sticky columns, and instance control all import from `@virtuoso.dev/data-table` directly while the wrapper continues to provide the styled `DataTable`.\n","frontmatter":{"title":"Install With shadcn/ui","description":"Add the styled Virtuoso data table wrapper from the GitHub shadcn registry and start with a polished default table.","sidebar":{"label":"Shadcn Install"}},"isInternal":false,"tokens":1344,"sizeBytes":5567},{"name":"02.headless.md","path":"packages/data-table/docs/1.installation/02.headless.md","rawUrl":"https://raw.githubusercontent.com/petyosi/react-virtuoso/HEAD/packages/data-table/docs/1.installation/02.headless.md","title":"1.installation Skill","category":"anthropic-skill","format":"markdown","content":"---\ntitle: Install The Headless Package\ndescription: Use the headless Virtuoso data table package directly when you need full control over styling and composition.\nsidebar:\n label: Headless Install\n---\n\nThe headless package gives you `VirtuosoDataTable`, `Column`, `ColumnHeader`, and `Cell` without any preset styling. Pick it when you already have a design system, use non-Tailwind styling, or need fully custom markup around the table.\n\n## Install the package\n\n```bash\npnpm add @virtuoso.dev/data-table\n```\n\n`npm`, `yarn`, and `bun` work too.\n\n## Import structural styles\n\nThe package ships layout defaults (column sizing, box model) in a `@layer virtuoso` block. Import the stylesheet once in your app's CSS or entry point:\n\n```css\n@import '@virtuoso.dev/data-table/styles.css';\n```\n\n```typescript\nimport '@virtuoso.dev/data-table/styles.css'\n```\n\nThe `@layer virtuoso` wrapping puts these rules at the lowest cascade priority, so any plain CSS or Tailwind utility class overrides them.\n\n## Minimal headless example\n\n```tsx live wide file=App.tsx\nimport { Cell, Column, ColumnHeader, VirtuosoDataTable, localModel } from '@virtuoso.dev/data-table'\n\nimport { rows } from './data'\n\nconst currency = new Intl.NumberFormat('en-US', {\n currency: 'USD',\n style: 'currency',\n})\n\nconst model = localModel({ data: rows })\n\nexport default function App() {\n return (\n \n \n \n {() => Product
}\n \n \n {({ cellValue }) => (\n {String(cellValue)} \n )}\n | \n \n \n \n {() => Category
}\n \n \n {({ cellValue }) => (\n {String(cellValue)} \n )}\n | \n \n \n \n {() => (\n \n Price\n