docs(ui): clarify lobby re-enter starts at the map, only refresh restores
Tests · UI / test (pull_request) Successful in 2m32s

The single-URL restore replays the saved screen/view on an in-place
refresh only. Re-entering a game from the lobby resets activeView to the
map (lobby calls activeView.reset() before appScreen.go("game")), and
browser Back / the return-to-lobby control exit to the lobby. Spell this
out so the refresh-restore is not mistaken for a per-re-enter restore.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ilia Denisov
2026-05-23 22:14:15 +02:00
parent c1672224a6
commit 1dadf08672
+5 -1
View File
@@ -95,7 +95,11 @@ label `game.shell.menu.return_to_lobby`); it calls
`appScreen` / `activeView` persist a snapshot (screen, game id, view + `appScreen` / `activeView` persist a snapshot (screen, game id, view +
sub-params) to `sessionStorage` (`galaxy-app-nav`) on every mutation sub-params) to `sessionStorage` (`galaxy-app-nav`) on every mutation
and read it back once at construction, so a refresh restores the last and read it back once at construction, so a refresh restores the last
screen and view. On a full load the dispatcher records the restored screen and view. Re-entering a game from the lobby is not a restore: the
lobby resets `activeView` to the map before `appScreen.go("game")`, so
only an in-place refresh replays the saved view — browser Back and the
in-game return-to-lobby control both exit to the lobby. On a full load
the dispatcher records the restored
game id (`appScreen.restoredGameId`); the game shell's boot path then game id (`appScreen.restoredGameId`); the game shell's boot path then
validates it against the player's game list. `GameStateStore.init` validates it against the player's game list. `GameStateStore.init`
looks the game up through `listMyGames` / `findGame`, and if the game looks the game up through `listMyGames` / `findGame`, and if the game