Migrate storage mappings table to GraphQL - #2031
Conversation
Replace the PostgREST-backed storage mappings settings table with a cursor-paginated GraphQL query (usePaginatedStorageMappings). - Drop the getStorageMappings PostgREST helper and the EntityTable / TableHydrator / selectable-table Zustand plumbing it required. - Render a plain MUI Table with TablePagination driven by useCursorPagination; forward pagination only, no search or column sorting (the storageMappings query supports neither). - Retype rows to StorageMappingTableRow (catalogPrefix / spec) and remove the "Last Updated" column, which the query does not expose. - Invalidate the storageMappings query in the URQL cache on createStorageMapping / updateStorageMapping, replacing the manual useStorageMappingsRefresh mechanism. - Add the storageMappingsTable.error.loadFailed message.
⚪ Code HealthNo change to the dead-code surface. 48 Unused files
64 Unused exports
26 Unused exported types
14 Unused exported enum members
5 Unused dependencies
3 Unused devDependencies
|
|
|
||
| const selectedTenant = useTenantStore((state) => state.selectedTenant); | ||
| const { storageMappings, fetching, error, pageInfo, pageSize } = | ||
| usePaginatedStorageMappings(cursor); |
There was a problem hiding this comment.
The pagination state isn't tied to the selected tenant. Settings keeps this table mounted when TenantSelector changes selectedTenant, so if I'm on page 2+ for tenant A and select tenant B, this sends A's after cursor with B's underPrefix. Best case we skip B's first page; worst case the query errors or returns zero edges. The latter strands the table because the footer below is gated on storageMappings.length > 0, so there isn't even a Previous button to recover.
Can we reset to page 0 when the tenant changes (or key/remount the paginated table by tenant)? I'd also mirror the Access Links / Refresh Tokens empty-page recovery using goToPage(currentPage - 1) after a completed zero-row fetch.
| columnToSort, | ||
| setColumnToSort, | ||
| } = useTableState('sm', 'catalog_prefix'); | ||
| const { currentPage, cursor, onPageChange } = useCursorPagination(); |
There was a problem hiding this comment.
useCursorPagination has a history bug that this makes reachable: after moving backwards, forward navigation always appends instead of truncating/replacing the abandoned tail. Reproduced sequence: 1 → 2 → 3 → 2 → 3 → 4 → 5 → 4; the final "page 4" uses the page-3 cursor. It needs enough rows and some backtracking, so low likelihood, but the label and data diverge once it happens.
Worth fixing the shared hook's forward branch to trim history to the target page before adding nextCursor, and pinning it with this sequence.
2 participants
Summary
Migrates the Storage Mappings settings table from PostgREST to a cursor-paginated GraphQL query, and drops react-intl from the touched components.
usePaginatedStorageMappings(forward cursor pagination); remove thegetStorageMappingsPostgREST helper and the EntityTable / TableHydrator / selectable-table Zustand plumbing it required.Table+TablePaginationdriven byuseCursorPagination— no search or column sorting (the query supports neither); the "Last Updated" column is gone since the query doesn't expose it.storageMappingsquery in the URQL cache on create/update, replacing the manual refresh mechanism.