Navbar: API link should be right-aligned / far right #326

New issue

Closed

opened 2026-09-11 14:53:02 +00:00 by crueber · 1 comment

crueber commented

2026-09-11 14:53:02 +00:00

Owner

What's requested

The Issues tab (/:owner/:name/issues) should default to showing open issues only. Today it shows open and closed together; a user wanting the closed ones opts in via the State filter.

Current state (code evidence)

web/src/pages/Issues.jsx:31-37 — the list query reads state: search.state || "", and the server treats an empty state as "open + closed" (the filter select's own labels confirm it: empty option reads "open + closed", Issues.jsx:96-101).
So a bare visit to the Issues tab (no ?state= param) fetches and renders both states intermixed.
The filter select itself offers "open + closed / open / closed" — that stays; only the default changes.
The State select's value binding reads the same search.state (:100), so it will naturally show "open" as the selected option once the default flips — verify that binding reflects the effective default rather than the raw param.

Proposed change

Default state to "open" when the URL carries no state param: state: search.state ?? "open" is NOT enough (empty string is a legitimate "both" choice from the select) — the right shape is: treat absent param as open, keep explicit ?state= (including a possible "both" representation) honored as-is. Implementation detail for the implementer: either reserve state=all/both as the explicit both-value and migrate the select's "open + closed" option to it, or treat undefined as open and "" as both — pick one, keep the URL honest, and note it in the PR.
The same default should apply to the milestone-filtered views that land on this page (?milestone=<id> from the milestones page "View issues" button, #314) — they inherit the query default, so they'll show open-only too. That matches GitHub behavior; call it out in the PR so it's a decision, not an accident.
The pulls list (Pulls.jsx) is NOT in scope of this request — leave as-is unless the user says otherwise (flag the inconsistency in the PR body for a follow-up decision).

Acceptance criteria

Visiting /:owner/:name/issues with no state param shows only open issues; the State select visibly reads "open".
Choosing "open + closed" from the select shows both, and that choice is reflected in the URL (shareable/refreshable).
Deep links with an explicit state (?state=closed, etc.) are honored exactly.
Milestone-filtered landings (?milestone=) default to open-only as well.
Pagination/after cursor behavior unaffected (key already includes the query JSON).
Headless test for the default-resolution logic (absent → open; explicit both → both; explicit closed → closed).

## What's requested The Issues tab (`/:owner/:name/issues`) should default to showing **open issues only**. Today it shows open and closed together; a user wanting the closed ones opts in via the State filter. ## Current state (code evidence) - `web/src/pages/Issues.jsx:31-37` — the list query reads `state: search.state || ""`, and the server treats an empty `state` as "open + closed" (the filter select's own labels confirm it: empty option reads "open + closed", `Issues.jsx:96-101`). - So a bare visit to the Issues tab (no `?state=` param) fetches and renders both states intermixed. - The filter select itself offers "open + closed / open / closed" — that stays; only the **default** changes. - The State select's value binding reads the same `search.state` (`:100`), so it will naturally show "open" as the selected option once the default flips — verify that binding reflects the effective default rather than the raw param. ## Proposed change - Default `state` to `"open"` when the URL carries no `state` param: `state: search.state ?? "open"` is NOT enough (empty string is a legitimate "both" choice from the select) — the right shape is: treat *absent param* as `open`, keep explicit `?state=` (including a possible "both" representation) honored as-is. Implementation detail for the implementer: either reserve `state=all`/`both` as the explicit both-value and migrate the select's "open + closed" option to it, or treat `undefined` as open and `""` as both — pick one, keep the URL honest, and note it in the PR. - The same default should apply to the milestone-filtered views that land on this page (`?milestone=<id>` from the milestones page "View issues" button, #314) — they inherit the query default, so they'll show open-only too. That matches GitHub behavior; call it out in the PR so it's a decision, not an accident. - The pulls list (`Pulls.jsx`) is NOT in scope of this request — leave as-is unless the user says otherwise (flag the inconsistency in the PR body for a follow-up decision). ## Acceptance criteria - [ ] Visiting `/:owner/:name/issues` with no state param shows only open issues; the State select visibly reads "open". - [ ] Choosing "open + closed" from the select shows both, and that choice is reflected in the URL (shareable/refreshable). - [ ] Deep links with an explicit state (`?state=closed`, etc.) are honored exactly. - [ ] Milestone-filtered landings (`?milestone=`) default to open-only as well. - [ ] Pagination/`after` cursor behavior unaffected (key already includes the query JSON). - [ ] Headless test for the default-resolution logic (absent → open; explicit both → both; explicit closed → closed).

crueber closed this issue

2026-09-11 14:53:21 +00:00

crueber commented

2026-09-11 14:53:21 +00:00

Author

Owner

Filed in error (wrong body / duplicate) — closed.