Decide what happens to the orphaned IssuesTable

[frankieramirez]

Part of #353.

Question

IssuesTable.tsx has no caller. What happens to it?

Established in #364: grep -rn "IssuesTable" across the frontend finds only the file's own declaration and an unused IssuesTableProps (types/components.ts:62, re-exported at types/index.ts:102). #137 "Major frontend redesign" (2026-04-18) removed both the import and <IssuesTable issues={issues} isManga={isManga} comicId={comicId} /> from SeriesDetailPage, which now hand-rolls the list at :646 with filteredIssues.map(...). 834 lines, 0.00% coverage, dead three months.

This is a scoping decision, not a technical one — the map's destination names the tables it covers, and two of them turn out not to exist.

Decide:

1. Delete, revive, or rule out of scope? Deleting removes two of the eight instances and the map's getRowId/pruning work shrinks accordingly. Reviving means SeriesDetailPage's hand-rolled list goes back to TanStack — a rendering change the map has consistently ruled out elsewhere (ArcIssueTable, SearchResultsTable, and chore(frontend): Remove the unused schema-driven table system #308's warning about generalising surfaces with no callers). Ruling it out of scope leaves the dead file in place and out of the migration.
2. Does the destination get redrawn? It says useTableState owns state for all seven tables and that useActivityTableState is deleted. If IssuesTable goes, the destination should say six live instances in five files, not seven.
3. Two decisions rest on this file and need re-basing either way. Decide how the hook expresses pagination across four models #360's model B (TanStack slices, uncontrolled — initialState.pagination.pageSize: 50) has chaptersTable as its only instance, so the uncontrolled arm of pagination?: { pageSize } currently serves nothing live. And Decide the hook's surface area and the selection ownership model #359 justified selectAllScope being required on IssuesTable's page scope; Validate the interface against all seven call sites and measure their coverage #364 found SeriesTable:485 is also page-scoped, so the parameter survives on live evidence — but at 20–24 rows a page, not the 50 that made Decide the hook's surface area and the selection ownership model #359's argument vivid.
4. The map records a "live fix: Decode queue table selection by row identity #307-class defect" here. Validate the interface against all seven call sites and measure their coverage #364 confirms it is source-consistent — the decode at :186-193 indexes filteredByStatus, :554 passes rowSelection with no getRowId, and setStatusFilter (:635) never clears it — but unreachable. If the file is deleted, that stops being one of the map's two identity defects and the fog entry Where the two identity fixes ship covers one, not two.

Note: #308 is the standing warning in the map's Notes — 7,447 lines deleted for having no callers. This is the same shape at smaller scale, and the map's own reframe ("generalise a hook that already has callers") argues against carrying a callerless table through the migration.

[frankieramirez]

IssuesTable.tsx is deleted, along with its exclusive tail. Not revived, not left in place — and the deletion pre-ships on main ahead of the seam, the same call #372 made for the deep-link fix.

The scoping call

Confirmed against origin/main (f12c9914, which already carries #384): the only IssuesTable hits anywhere in the repo are the component's own declaration and a stale IssuesTableProps in types/components.ts:62 — which does not even match the component's real props (no isManga, no comicId), so the exported type had drifted before #137 ever unhooked it.

Reviving was never the option the ticket framed it as. SeriesDetailPage:646 is not a degraded stopgap standing in for a table: it is a designed six-column grid with arc, annual and separate-intent handling and filter chips, deliberately read-only, paired with the series-level search-missing dialog. What #137 actually dropped was per-issue queue/unqueue, bulk queue/metatag, global search, the manga volumes view and pagination. Putting TanStack back means reverting a visual redesign and re-deciding those product features — a different destination, not this map's.

Deleting follows from the map's own Notes. #308 is the standing warning (7,447 lines deleted for having no callers) and the reframe is generalise a hook that already has callers. Migrating a component with zero callers is the same trap at smaller scale.

The sweep

Deletion orphans four more things, all verified to have no other consumer:

• hooks/useMetadata.ts — the whole 24-line file. useBulkMetatag had exactly one caller.
• data-table/cells/ProgressBarCell.tsx — 19 lines. cells/ survives via CoverCell, used by WantedTable:93 and UpcomingTable:84.
• The VolumeGroup type (types/entities.ts:390, re-exported at types/index.ts:49).
• The stale IssuesTableProps (types/components.ts:63) and its re-export at types/index.ts:102.

All of it goes in one PR, verified by tsc and npm run lint. There is no knip, ts-prune or depcheck in this repo — nothing would ever have flagged the tail, which is the same reason the component itself sat dead for three months. That is the argument against a component-only deletion.

Noted, not ticketed: POST /api/metadata/metatag/bulk is live and maintained backend-side (comicarr/app/metadata/service.py:203, beside manual_metatag and group_metatag). Deleting the hook breaks nothing, but it makes explicit that the UI has had no metatag entry point at all since #137. A pre-existing product gap, out of scope for this map.

What the destination becomes

Grep on main gives 8 useReactTable instances in 6 files today; after deletion, 6 in 5 files — SeriesTable, ImportTable, WantedTable, UpcomingTable, and ActivityPage's two. The destination is redrawn to that count, IssuesTable.tsx joins useActivityTableState in its deletion list, and the two remaining #307-class defects becomes the one.

"The three selection decoders become one" survives untouched. IssuesTable shared SeriesTable's bucket — local useState, bulk bar rendered inside — so every ownership model keeps a live instance: SeriesTable:156 local-decode, Wanted/Upcoming parent-owned via useMemo, ImportTable:281 local-plus-emit.

Re-basing the two dependent decisions

#360 needs no re-basing, and this ticket's premise about it is wrong. There is no "uncontrolled arm of pagination?: { pageSize }" to strand: #360's resolution absorbed model B into controlled mode outright — "initialState.pagination.pageSize: 50 becomes pagination: { pageSize: 50 }". The argument has one shape, present-vs-absent, and both cases still have live callers (SeriesTable present; five instances absent). What actually changes is smaller than re-basing: chaptersTable drops out of #360's migration checklist, and getPaginationRowModel is now imported in exactly one file rather than two.

#359's selectAllScope stays required with no default — but the honest reason has changed. The split after deletion is the same 1:3 with a new exemplar: SeriesTable:485 page-scoped, Wanted:75 / Upcoming:69 / Import:294 filtered-scoped. What #364 could not see is that those three import no getFilteredRowModel, no getPaginationRowModel and no globalFilter at all — TanStack's entire row set is the current server page, so getIsAllRowsSelected() and getIsAllPageRowsSelected() are provably identical there. Their filtered-scope call is not a choice; it is the only sensible call in a table with no pagination row model.

So the parameter now changes behaviour at exactly one call site. It stays required anyway, on #359's original reasoning rather than on the vividness of 50 rows a page: scope is semantics, not identity, so the constraint says name it. The three inert callers write "filtered" as an assertion of intent that stays correct if they ever gain a client-side row model. Hard-coding "filtered" was not available — it would silently change SeriesTable's select-all, a behaviour change outside the map's selection-identity exception.

The identity-defect count

The map's live #307-class defect on this file was already downgraded by #364 to source-consistent but unreachable. Deleting the file removes it as a defect entirely, so the fog entry Where the identity fixes ship covers one fix — ActivityPage:590 — not two.

Shipping

A new unblocked wayfinder:task child of the map, executable immediately: Delete the orphaned IssuesTable and its exclusive tail. Pre-shipped rather than folded into a migration PR because it depends on nothing and shrinks everything downstream — #365's parity-proof scope, the migration-order fog, and #366's per-table PR list are all defined over a smaller set once it is gone. A pure deletion is also the cheapest possible thing to review in isolation; mixed into a behaviour-preserving refactor, the diff stops being reviewable as either one. Branch refactor/delete-orphaned-issues-table, patch changeset, since nothing user-visible changes.

[frankieramirez]

Resolved: delete, with the exclusive tail. Execution pre-ships on main as #389.