fix(ui): F8-04b lobby — auto-expand first available games sub + hide empty invitations #64

2026-05-27T08:18:16Z

developer commented

2026-05-27 08:18:16 +00:00

Follow-up nits on F8-04b spotted post-merge.

Summary

Bare-lobby resolver (lobby-screen.svelte) used to redirect unconditionally to games-recruitment. Now it awaits the lobby fan-out + account fetch, then hands off to the same firstVisibleGamesScreen helper the sidebar uses — so a fresh entry with games in the roster lands on active-past, while recruitment stays the deterministic canonical fallback.
games-invitations was unconditionally visible in the sidebar. Now hidden when the pending-invites list is empty (mirroring the active-past rule). The lobby shell's auto-kick effect treats invitations symmetrically: accepting / declining the last invite routes the player to the next visible sub-page once the fan-out has resolved.
acceptInvite reorders its writes to setMyGames-before-removeInvitation, so both mutations land in the same microtask and the auto-kick sees the freshly added game already in myGames — without it the player would bounce through recruitment for one frame before settling on active-past.

The visibility predicates and canonical order moved to src/lib/lobby-nav.ts (pure helper) so the sidebar and the resolver share a single source of truth.

Test plan

cd ui/frontend && npm test — 814 passed (11 new in lobby-nav.test.ts).
cd ui/frontend && npm run check — clean.
cd ui/frontend && npm run build — clean.
ui-test.yaml on gitea — pending.
Manual verification on dev: with a game in the roster, lobby auto-opens on active-past (not recruitment); invitations sidebar item appears only when there is at least one pending invite.

Doc sync

ui/docs/lobby.md updated: invitations visibility rule + first-visible resolver path now describe the new behavior.

Follow-up nits on F8-04b spotted post-merge. ## Summary - Bare-`lobby` resolver (`lobby-screen.svelte`) used to redirect unconditionally to `games-recruitment`. Now it awaits the lobby fan-out + account fetch, then hands off to the same `firstVisibleGamesScreen` helper the sidebar uses — so a fresh entry with games in the roster lands on `active-past`, while `recruitment` stays the deterministic canonical fallback. - `games-invitations` was unconditionally visible in the sidebar. Now hidden when the pending-invites list is empty (mirroring the `active-past` rule). The lobby shell's auto-kick effect treats invitations symmetrically: accepting / declining the last invite routes the player to the next visible sub-page once the fan-out has resolved. - `acceptInvite` reorders its writes to `setMyGames`-before-`removeInvitation`, so both mutations land in the same microtask and the auto-kick sees the freshly added game already in `myGames` — without it the player would bounce through `recruitment` for one frame before settling on `active-past`. The visibility predicates and canonical order moved to `src/lib/lobby-nav.ts` (pure helper) so the sidebar and the resolver share a single source of truth. ## Test plan - [x] `cd ui/frontend && npm test` — 814 passed (11 new in `lobby-nav.test.ts`). - [x] `cd ui/frontend && npm run check` — clean. - [x] `cd ui/frontend && npm run build` — clean. - [ ] `ui-test.yaml` on gitea — pending. - [ ] Manual verification on dev: with a game in the roster, lobby auto-opens on `active-past` (not `recruitment`); `invitations` sidebar item appears only when there is at least one pending invite. ## Doc sync - `ui/docs/lobby.md` updated: `invitations` visibility rule + first-visible resolver path now describe the new behavior.

developer added 1 commit 2026-05-27 08:18:17 +00:00

fix(ui): F8-04b lobby — auto-expand first available games sub + hide empty invitations

Tests · UI / test (push) Waiting to run

Details

Tests · UI / test (pull_request) Successful in 2m45s

Details

6fbab5417f

Two follow-up nits on the F8-04b sidebar:

1. The bare-`lobby` resolver (lobby-screen.svelte) redirected to
   `games-recruitment` unconditionally on mount. With games already
   in the player's roster the sidebar then highlighted the wrong
   sub-page. The resolver now awaits the lobby fan-out + account
   fetch, then hands off to the same `firstVisibleGamesScreen` helper
   the sidebar uses — so a fresh entry with games lands on
   `active-past`, the canonical-order fallback stays `recruitment`.

2. `games-invitations` was unconditionally visible in the sidebar.
   Now it follows the `active-past` rule: hidden until the
   pending-invites list reports >=1. The lobby shell's auto-kick
   effect treats it symmetrically — accepting / declining the last
   invite moves the player to the next visible sub-page once the
   fan-out has resolved.

Acceptance order in games-invitations-screen.acceptInvite was also
swapped to setMyGames-before-removeInvitation: both mutations land
in the same microtask, so the new auto-kick sees the freshly added
game in `myGames` when invitations drop to zero and routes the
player to `active-past` instead of bouncing through `recruitment`.

The visibility predicates and canonical order live in the new
`src/lib/lobby-nav.ts` pure helper, shared between the sidebar and
the resolver so they cannot disagree. Unit tests cover every
combination of (hasMyGames, hasInvitations, isPaidOrDev).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

owner approved these changes 2026-05-27 08:30:37 +00:00

developer merged commit 208d30073b into development

2026-05-27 08:31:07 +00:00

developer deleted branch feature/lobby-default-expand-and-empty-invitations

2026-05-27 08:31:07 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: developer/galaxy-game#64