[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}(RESTMessageResponse와 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검증없는 단언이 없다 BroadcastMessage를ChatMessage로 매핑하는 정규화 유틸(있으면)의 필드 매핑이 계약과 일치한다- Invitation 상태 유니온이 BE 상태 전이 표의 5개 값과 일치한다
RoomUnreadResponse필드가GET /rooms/me/unread계약과 일치한다