Lobby: Support WS Based Solution

Overview & Context

Replace the REST-only pre-join lobby with a live, signaling-driven lobby. Instead of sending the display name in the /start body and auto-joining, the web app opens the WebSocket first, receives a joined_lobby event with a can_enter flag, and only sends the display name when the user confirms via enter_room / enter_waiting_room.

Technical Design & Interfaces

Incoming (core)

  • joined_lobby { participantId, connectionId, canEnter: boolean, displayName? }

Incoming (moderation)

  • display_name_assigned { newName?: string } - locks the name; null/absent re-allows free naming

Outgoing (core)

  • enter_room { displayName? } - used when canEnter === true.
  • enter_waiting_room { displayName } - used when canEnter === false.

State (roomSlice)

  • connectionState: Lobby, canEnter?: boolean, lobbyDisplayName?: string.

Frontend & UI Requirements

Translations

English German
Enter now Jetzt beitreten
Request to join Beitritt anfragen

Implementation Notes

  • Auto-open the connection when the lobby view mounts (guard against repeat connects), render LobbyView for the new Lobby connection state
  • Keep password_required as an optional, default-false field for future password support (until {TICKET} is fixed

Implementation Tasks

  • Add Lobby connection state + joined_lobby type/handler
  • Add enter_room / enter_waiting_room outgoing commands
  • Stop auto-join on connect - open the WS without a name
  • Rework LobbyView for connect-first: live CTA (Enter now / Request to join) + name lock via display_name_assigned
  • Write unit tests (handlers + LobbyView)

Definition of Done (DoD)

  • Code passes linting and type checks
  • Manual verification successful (Tested on Chrome/Firefox)
  • Add unit tests
  • Add release label after merge
Edited by Maximilian Fuß