chore: refresh registry metadata and docs
This commit is contained in:
+31
-21
@@ -2,11 +2,16 @@
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
Implemented
|
||||
|
||||
The first `DataTable` slice now ships in `packages/ui` with stories, tests, and registry
|
||||
distribution support. This RFC remains as the design record for the shipped scope and the
|
||||
guardrails for future follow-up work.
|
||||
|
||||
## Summary
|
||||
|
||||
`DataTable` is the next high-value advanced pattern for `@ai-ui/ui`, but it should not ship as a giant "kitchen sink" component.
|
||||
`DataTable` is now a shipped advanced pattern for `@ai-ui/ui`, and it should continue to avoid
|
||||
turning into a giant "kitchen sink" component.
|
||||
|
||||
The recommended path is:
|
||||
|
||||
@@ -34,11 +39,13 @@ Relevant current building blocks already exist in `packages/ui`:
|
||||
- overflow and contextual actions: `DropdownMenu`, `Popover`, `Tooltip`, `Sheet`, `Dialog`, `Toast`
|
||||
- empty and first-run states: `EmptyState`
|
||||
|
||||
That means the main missing piece for list-heavy product surfaces is not another primitive. It is a stable data presentation pattern.
|
||||
At RFC authoring time, the main missing piece for list-heavy product surfaces was not another primitive.
|
||||
It was a stable data presentation pattern.
|
||||
|
||||
## Problem statement
|
||||
|
||||
Today the design system can express forms, overlays, command/search, and empty states, but it cannot yet express a reusable operational list surface such as:
|
||||
Before this work, the design system could express forms, overlays, command/search, and empty
|
||||
states, but it could not yet express a reusable operational list surface such as:
|
||||
|
||||
- release queues
|
||||
- approval backlogs
|
||||
@@ -94,14 +101,16 @@ This RFC is anchored in the current repo, not an idealized future state.
|
||||
|
||||
### Dependency constraints
|
||||
|
||||
Current `packages/ui/package.json` has no table model dependency, no date library, and no grid engine.
|
||||
When this RFC was written, `packages/ui/package.json` had no table model dependency, no date
|
||||
library, and no grid engine.
|
||||
|
||||
That means the first `DataTable` implementation must either:
|
||||
That meant the first `DataTable` implementation had to either:
|
||||
|
||||
- hand-roll row modeling, sorting, selection, and visibility management, or
|
||||
- adopt a focused headless dependency
|
||||
|
||||
Hand-rolling is not recommended for this repo stage.
|
||||
Hand-rolling was not recommended for this repo stage, and the shipped implementation now uses
|
||||
`@tanstack/react-table` internally.
|
||||
|
||||
## Recommendation
|
||||
|
||||
@@ -353,7 +362,7 @@ At least one smoke scenario should cover:
|
||||
- selecting rows reveals a bulk-action affordance
|
||||
- opening row detail in `Sheet` still works
|
||||
|
||||
## Release plan
|
||||
## Original release plan
|
||||
|
||||
### Stage 0: RFC and composition rehearsal
|
||||
|
||||
@@ -392,9 +401,9 @@ Only if justified by real product usage:
|
||||
- virtualization
|
||||
- advanced filters
|
||||
|
||||
## Likely file layout
|
||||
## Implemented file layout
|
||||
|
||||
When implementation begins, the initial table slice should probably live in:
|
||||
The initial table slice now lives in:
|
||||
|
||||
```txt
|
||||
packages/ui/src/components/data-table.tsx
|
||||
@@ -403,13 +412,14 @@ packages/ui/src/components/data-table.test.tsx
|
||||
apps/docs/src/components/data-table.stories.tsx
|
||||
```
|
||||
|
||||
If the implementation grows into a larger family, the repo may eventually want a dedicated component folder, but the first slice should stay consistent with the current flat component layout.
|
||||
If the implementation grows into a larger family, the repo may eventually want a dedicated
|
||||
component folder, but the current slice still follows the flat component layout.
|
||||
|
||||
## Dependency recommendation
|
||||
|
||||
### Recommended
|
||||
### Current choice
|
||||
|
||||
- add `@tanstack/react-table` to `packages/ui`
|
||||
- use `@tanstack/react-table` inside `packages/ui`
|
||||
|
||||
### Not recommended for the first slice
|
||||
|
||||
@@ -420,7 +430,7 @@ If the implementation grows into a larger family, the repo may eventually want a
|
||||
|
||||
The first implementation should minimize dependency expansion and keep the complexity budget focused on a single new capability.
|
||||
|
||||
## Open questions
|
||||
## Follow-up questions
|
||||
|
||||
1. Should the public column type stay fully source-owned, or should the first release expose a thin alias around TanStack column defs?
|
||||
2. Should the first release include client-side search/filter state inside `DataTable`, or should filtering remain externally controlled?
|
||||
@@ -428,12 +438,12 @@ The first implementation should minimize dependency expansion and keep the compl
|
||||
4. Should pagination UI be part of the root component family, or remain a separate companion component?
|
||||
5. Should row selection be opt-in only, or should the root always reserve structure for it?
|
||||
|
||||
## Decision
|
||||
## Result
|
||||
|
||||
The next `DataTable` implementation should:
|
||||
The shipped `DataTable` implementation:
|
||||
|
||||
- be built as an advanced pattern, not a primitive
|
||||
- be source-owned at the public API layer
|
||||
- use TanStack Table internally from the first implementation
|
||||
- ship as a narrow, headless/core-first operational table
|
||||
- defer scale features until real usage proves they are necessary
|
||||
- is built as an advanced pattern, not a primitive
|
||||
- is source-owned at the public API layer
|
||||
- uses TanStack Table internally from the first implementation
|
||||
- ships as a narrow, headless/core-first operational table
|
||||
- defers scale features until real usage proves they are necessary
|
||||
|
||||
Reference in New Issue
Block a user