What
The terminal forgets g (grouping) between runs. The browser remembers its equivalent.
Noticed while building the season tree (#67) and the watch position (#69), and
deliberately left out of both — it is a decision about the TUI's view toggles generally,
not a loose end of either feature.
Where the two surfaces stand today
| View option |
Terminal |
Browser |
| sort |
persisted (via the store) |
persisted (parseSort, localStorage) |
| grouping |
session only — useState(true), Results.tsx:301 |
persisted (parseGrouping, localStorage) |
| layout (list/grid) |
n/a |
persisted (parseLayout) |
| preview pane on/off |
session only — useState(true), Results.tsx:243 |
n/a |
| alive-only |
session only — useState(false), Results.tsx:283 |
session only |
| text filter |
session only, and should stay that way |
session only |
So it is not "the terminal does not persist view options" — sort already does. It is
that sort persists and the others do not.
The counter-argument, which is in the code
Results.tsx:298 states the current position deliberately:
Local state, like previewOn and aliveOnly — the browser stores its own in
localStorage and neither surface has ever persisted the other's view options.
That is a defensible reading: the browser's localStorage is its own private thing rather
than a shared setting the terminal is failing to honour, and a per-session default of ON
is not obviously wrong for any of these.
The question worth answering
Not "should g persist" on its own, but: which of the terminal's view toggles are
preferences and which are per-session? sort has already been answered one way. Pick
the same answer for grouping and the preview pane, or write down why they differ.
aliveOnly is arguably genuinely per-session — it is a "let me narrow this one search"
control, closer to the text filter than to a preference.
If the answer is "persist grouping"
Small: a config field, the read at startup, the write in the g handler. The one thing to
be careful about is the rule CONTRIBUTING/CLAUDE.md already states for config writes
from the web — read-modify-write per change, never a held snapshot, because serve --web
is a separate process from a running TUI.
Not urgent
Nothing is broken; g works, it just starts fresh each run.
What
The terminal forgets
g(grouping) between runs. The browser remembers its equivalent.Noticed while building the season tree (#67) and the watch position (#69), and
deliberately left out of both — it is a decision about the TUI's view toggles generally,
not a loose end of either feature.
Where the two surfaces stand today
parseSort, localStorage)useState(true),Results.tsx:301parseGrouping, localStorage)parseLayout)useState(true),Results.tsx:243useState(false),Results.tsx:283So it is not "the terminal does not persist view options" —
sortalready does. It isthat
sortpersists and the others do not.The counter-argument, which is in the code
Results.tsx:298states the current position deliberately:That is a defensible reading: the browser's localStorage is its own private thing rather
than a shared setting the terminal is failing to honour, and a per-session default of ON
is not obviously wrong for any of these.
The question worth answering
Not "should
gpersist" on its own, but: which of the terminal's view toggles arepreferences and which are per-session?
sorthas already been answered one way. Pickthe same answer for grouping and the preview pane, or write down why they differ.
aliveOnlyis arguably genuinely per-session — it is a "let me narrow this one search"control, closer to the text filter than to a preference.
If the answer is "persist grouping"
Small: a config field, the read at startup, the write in the
ghandler. The one thing tobe careful about is the rule
CONTRIBUTING/CLAUDE.mdalready states for config writesfrom the web — read-modify-write per change, never a held snapshot, because
serve --webis a separate process from a running TUI.
Not urgent
Nothing is broken;
gworks, it just starts fresh each run.