[FE-02] 채팅 도메인 타입 정의 (chat-types)

작업 내용 (설계 의도)

변경 사항

근거: 20260704-채팅시스템고도화-design-fe-app.md “API 연동 표”·BE TDD “REST API 계약”·“STOMP 계약”.

채팅·읽음·초대·게스트 관련 신규 DTO 타입을 정의한다. 기존 api/types.ts(공유 파일)는 수정하지 않고 신규 파일 api/chat-types.ts에 정의해 Single Writer를 지킨다(다른 티켓과 충돌 방지).

  • STOMP 페이로드: BroadcastMessage{messageId,userId,content,createdAt}, TypingEvent{userId,typing}, ReadEvent{userId,lastReadMessageId}.
  • FE 내부 정규화 타입: ChatMessage{id,roomId,senderId,content,sentAt}(REST MessageResponse와 STOMP 병합 형태).
  • 읽음/안읽은: RoomUnreadResponse{roomId,unreadCount}, UnreadResponse, MarkReadRequest{lastReadMessageId}.
  • 게스트 초대: InvitationResponse, InviteGuestRequest{inviteeUserId,canSpeak,expiresInDays}, 상태 enum(PENDING|ACCEPTED|REJECTED|REVOKED|EXPIRED).
  • Room 확장(역제안 반영, optional): RoomContextType(COMMUNITY|GOODS_PRODUCT), RoomListItem(name·lastMessagePreview·lastMessageAt·unreadCount 병합용).

any·검증 없는 단언 금지. BE 계약과 필드명·타입 1:1. 계약 미정의 응답(InvitationResponse 등)은 설계 문서 “역제안” 항목 기준으로 초안 정의하고 주석으로 “BE 확정 대기” 표기.

의존

  • 없음 (wave 1)

다이어그램

클래스 의존

flowchart LR
    ChatTypes[chat-types.ts] --> UsedByApi[api/chat.ts]
    ChatTypes --> UsedBySocket[useChatSocket.ts]
    ChatTypes --> UsedByInv[api/invitation.ts]
    ChatTypes --> UsedByScreens[방/초대 화면]

테스트 케이스

  • (타입 전용 티켓) tsc --noEmit가 통과하고 any·as 검증없는 단언이 없다
  • BroadcastMessageChatMessage로 매핑하는 정규화 유틸(있으면)의 필드 매핑이 계약과 일치한다
  • Invitation 상태 유니온이 BE 상태 전이 표의 5개 값과 일치한다
  • RoomUnreadResponse 필드가 GET /rooms/me/unread 계약과 일치한다