refactor: split SessionDetail.tsx (1280 lines, complexity 134) #451

New issue

Open

opened 2026-07-25 23:32:21 +02:00 by dries · 0 comments

dries commented

2026-07-25 23:32:21 +02:00

Owner

Code-quality audit (P2). frontend/src/pages/session-detail/SessionDetail.tsx:142 — ESLint reports the SessionDetail function at 1280 lines and complexity 134 (limits: 150 / 20). 20+ useState, 25+ effects, 8 refs mirroring state.

Why it matters

This is the app's primary screen. At complexity 134 no reviewer can reason about which of the 25 effects will re-run for a given state change, which is exactly how the prop-to-ref staleness bugs in this area keep recurring. All 68 repo-wide ESLint findings are warn-only (40 complexity, 28 max-lines-per-function), so nothing stops it growing.

Related outliers in the same cluster, worth mentioning but not necessarily fixing here:

Composer.tsx:46 — ComposerImpl, complexity 82, 1167 lines (see the CustomEvent ticket).
useSessionActions.ts:373 — async arrow, complexity 61.
useSession.ts:211 — useSession, 453 lines.

Suggested fix

Extract along seams that already exist in the file:

Modal/dialog cluster (SessionDetail.tsx:1522-1603: RenameModal, and the siblings around it) into a <SessionModals> component driven by one discriminated-union activeModal state instead of N booleans.
The prompt reverse-sync effects into a useSessionPromptSync hook.
handleCommand into a command table (Record<string, (args: string) => void>) instead of an if/else chain — this alone removes a large slice of the complexity score.

Acceptance criteria

SessionDetail under 300 lines and complexity under 40.
Extracted hooks/components have their own tests.
No behaviour change: existing session-detail tests and e2e specs pass unchanged.

Effort: L.

Code-quality audit (P2). `frontend/src/pages/session-detail/SessionDetail.tsx:142` — ESLint reports the `SessionDetail` function at **1280 lines** and **complexity 134** (limits: 150 / 20). 20+ `useState`, 25+ effects, 8 refs mirroring state. ## Why it matters This is the app's primary screen. At complexity 134 no reviewer can reason about which of the 25 effects will re-run for a given state change, which is exactly how the prop-to-ref staleness bugs in this area keep recurring. All 68 repo-wide ESLint findings are warn-only (40 `complexity`, 28 `max-lines-per-function`), so nothing stops it growing. Related outliers in the same cluster, worth mentioning but not necessarily fixing here: - `Composer.tsx:46` — `ComposerImpl`, complexity 82, 1167 lines (see the CustomEvent ticket). - `useSessionActions.ts:373` — async arrow, complexity 61. - `useSession.ts:211` — `useSession`, 453 lines. ## Suggested fix Extract along seams that already exist in the file: - Modal/dialog cluster (`SessionDetail.tsx:1522-1603`: `RenameModal`, and the siblings around it) into a `<SessionModals>` component driven by one discriminated-union `activeModal` state instead of N booleans. - The prompt reverse-sync effects into a `useSessionPromptSync` hook. - `handleCommand` into a command table (`Record<string, (args: string) => void>`) instead of an if/else chain — this alone removes a large slice of the complexity score. ## Acceptance criteria - [ ] `SessionDetail` under 300 lines and complexity under 40. - [ ] Extracted hooks/components have their own tests. - [ ] No behaviour change: existing session-detail tests and e2e specs pass unchanged. Effort: L.