|
| 1 | +# Shared list/detail building blocks |
| 2 | + |
| 3 | +This directory hosts the reusable surface for list-and-detail pages: a |
| 4 | +filterable table, a Prev/Next/Sheet toolbar that walks the _same_ filtered |
| 5 | +subset on detail pages, and the inline-rename + sortable-header primitives |
| 6 | +that every list reuses. |
| 7 | + |
| 8 | +## Mental model |
| 9 | + |
| 10 | +``` |
| 11 | + ┌──────────────────────────────────────────┐ |
| 12 | + │ URL ?q=foo ?page=3 │ |
| 13 | + │ (source of truth — bookmarkable) │ |
| 14 | + └────────┬─────────────────────┬───────────┘ |
| 15 | + │ read/write │ read-only |
| 16 | + ▼ ▼ |
| 17 | + useTableQueryFilter useTableQueryFilterReader |
| 18 | + usePagination │ |
| 19 | + │ │ |
| 20 | + ▼ ▼ |
| 21 | + <DataTable> useNavigation |
| 22 | + (list page) │ |
| 23 | + │ ▼ |
| 24 | + ▼ <DetailNavigationToolbar> |
| 25 | + table_4_<path> (detail page) |
| 26 | + in localStorage |
| 27 | + (cold-start fallback) |
| 28 | +``` |
| 29 | + |
| 30 | +- **URL is authoritative.** Filter (`?q=`) and page (`?page=`) live in the |
| 31 | + URL so links/bookmarks always reproduce the user's view. |
| 32 | +- **Storage is a warm-restart bag.** The list page persists the URL filter |
| 33 | + into `localStorage` under `table_4_<path>`. The detail page never writes |
| 34 | + storage and never replays storage into the URL — opening a shared link |
| 35 | + shows exactly what the link says. |
| 36 | +- **Prev/Next walks the same subset.** `DetailNavigationToolbar` runs the |
| 37 | + same matcher (`createTextMatcher`) the list filter uses, so siblings stay |
| 38 | + in lockstep with what the user sees in the table. |
| 39 | + |
| 40 | +## Components |
| 41 | + |
| 42 | +| File | Role | |
| 43 | +| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | |
| 44 | +| [`detail-navigation/`](detail-navigation/) | Prev / Position / Next toolbar + listbox sheet for detail pages, and the navigation hooks that feed it. | |
| 45 | +| [`inline-edit/`](inline-edit/) | Generic inline-edit input (Save/Cancel addons, Enter/Escape) plus the paired `useInlineEdit` state machine. | |
| 46 | + |
| 47 | +## Hooks |
| 48 | + |
| 49 | +| Hook | Where | Source of truth | Writes? | Notes | |
| 50 | +| --------------------------- | ------------------------------- | --------------- | ------- | ------------------------------------------------------------------ | |
| 51 | +| `useTableQueryFilter` | `@/hooks/` | URL `?q=` | yes | List pages. Restores from `localStorage` on cold start. | |
| 52 | +| `useTableQueryFilterReader` | `@/hooks/` | URL `?q=` | no | Detail pages. Storage-blind — shared links never gain stale `?q=`. | |
| 53 | +| `usePagination` | `@/hooks/` | URL `?page=` | yes | Canonicalizes `?page=1` away so the URL has one form per view. | |
| 54 | +| `useNavigation` | `detail-navigation/` (internal) | props | no | Pure computation of Prev/Next around a `currentId`. | |
| 55 | +| `useDetailNavigation` | `detail-navigation/` | URL + props | no | Bundles the three above into a single hook for detail pages. | |
| 56 | +| `useInlineEdit` | `inline-edit/` | local state | no | Edit-mode toggle + deferred focus (Radix dropdown race fix). | |
| 57 | +| `usePageStorageKeys` | `@/hooks/` | router | no | Resolves the three per-page storage keys reactively. | |
| 58 | + |
| 59 | +## Library helpers (in `@/lib/`) |
| 60 | + |
| 61 | +| Module | Purpose | |
| 62 | +| ------------------------- | ------------------------------------------------------------------------------------ | |
| 63 | +| `table-state.ts` | Unified `table_4_<path>` JSON slot. Carries filter + sorting + columnVis + pageSize. | |
| 64 | +| `view-options-storage.ts` | `viewOptions_4_<path>` for FileManager-style screens (folders-first, etc.). | |
| 65 | +| `storage-keys.ts` | Single source of truth for storage-key conventions and `getTopLevelPath`. | |
| 66 | +| `url-params.ts` | `URL_PARAMS` constants + `mergeHrefWithSearchParams` (preserves hash on merge). | |
| 67 | + |
| 68 | +## How to add a new list + detail pair |
| 69 | + |
| 70 | +1. **List page** (`/<entities>/`): |
| 71 | + |
| 72 | + ```tsx |
| 73 | + const { filter, setFilter } = useTableQueryFilter(); |
| 74 | + const { pageIndex, setPage } = usePagination(); |
| 75 | + |
| 76 | + return ( |
| 77 | + <DataTable |
| 78 | + columns={columns /* use <DataTableColumnHeader column={column} title="..." /> */} |
| 79 | + data={entities} |
| 80 | + filterColumn="title" |
| 81 | + filterValue={filter} |
| 82 | + onFilterChange={setFilter} |
| 83 | + onPageChange={setPage} |
| 84 | + pageIndex={pageIndex} |
| 85 | + /> |
| 86 | + ); |
| 87 | + ``` |
| 88 | + |
| 89 | +2. **Feature-scoped navigation hook** (`@/features/<entity>/use-<entity>-detail-navigation.ts`): |
| 90 | + |
| 91 | + ```ts |
| 92 | + const getLabel = (item: Entity) => item.title; |
| 93 | + const getHref = (item: Entity) => `/<entities>/${item.id}`; |
| 94 | +
|
| 95 | + export const useEntityDetailNavigation = (currentId: null | string | undefined) => { |
| 96 | + const { entities } = useEntities(); |
| 97 | +
|
| 98 | + return useDetailNavigation<Entity>({ currentId, getHref, getLabel, items: entities }); |
| 99 | + }; |
| 100 | + ``` |
| 101 | + |
| 102 | +3. **Detail page** (`/<entities>/:id`): |
| 103 | + |
| 104 | + ```tsx |
| 105 | + const { toolbarProps } = useEntityDetailNavigation(entityId); |
| 106 | +
|
| 107 | + return ( |
| 108 | + <header> |
| 109 | + <DetailNavigationToolbar<Entity> |
| 110 | + {...toolbarProps} |
| 111 | + sheetIcon={<Icon className="size-4" />} |
| 112 | + sheetTitle="Entities" |
| 113 | + renderItem={(item, isCurrent) => <span>{item.title}</span>} |
| 114 | + /> |
| 115 | + </header> |
| 116 | + ); |
| 117 | + ``` |
| 118 | + |
| 119 | +## Why URL > storage |
| 120 | + |
| 121 | +A user opens `/flows?q=alpha` in tab A. They navigate to flow B by clicking |
| 122 | +"Next" in the toolbar. They share `/flows/b?q=alpha` with a teammate. |
| 123 | + |
| 124 | +- The teammate opens the link cold. Their detail page reads `q=alpha` from |
| 125 | + the URL and renders Prev/Next over the filtered subset. |
| 126 | +- The teammate hits "Next". They land on `/flows/c?q=alpha` — still inside |
| 127 | + the filter, even though they never typed it. |
| 128 | + |
| 129 | +`useTableQueryFilterReader` is the key piece: it observes the URL but never |
| 130 | +writes anything, so a fresh detail-page mount can't accidentally inject the |
| 131 | +**previous tab's** `?q=` into the URL. |
| 132 | + |
| 133 | +## Why one storage key per page |
| 134 | + |
| 135 | +Before the unification, every list page wrote four storage keys |
| 136 | +(`column_4_/flows`, `sorting_4_/flows`, `filter_4_/flows`, `page_4_/flows`) |
| 137 | +in two different write paths (sync + debounced). Refreshing during a typing |
| 138 | +session could land you in an inconsistent state. The unified |
| 139 | +`table_4_<path>` slot is a single JSON object that all preferences live in; |
| 140 | +`migrateLegacyTableState` folds the four legacy keys into it on first mount |
| 141 | +and deletes them. |
| 142 | + |
| 143 | +## Testing notes |
| 144 | + |
| 145 | +- `vitest run` covers the pure utilities (`table-state`, |
| 146 | + `view-options-storage`, `url-params`), the hook behaviours |
| 147 | + (`use-pagination`, `use-table-query-filter`, `use-inline-edit`, |
| 148 | + `use-page-storage-keys`, `use-detail-navigation`), and the components |
| 149 | + (`detail-navigation/`, `data-table`). |
| 150 | +- jsdom doesn't ship `Element.prototype.scrollIntoView` or `ResizeObserver` |
| 151 | + — both are polyfilled in `vitest.setup.ts`. |
| 152 | +- React Testing Library auto-cleans the DOM after every test (see the same |
| 153 | + setup file). Tests can freely call `render` without leaking nodes. |
0 commit comments