dpdpdndn 블로그

FE-01-app-api-types-확장

NEW2 min read

[FE-01] 앱 api/types.ts 타입 계약 확장 (Post·Comment·Slot·Program)

작업 내용 (설계 의도)

변경 사항

BE 계약(두 TDD)을 앱 타입에 미러링한다. 여러 도메인 필드가 한 파일(mobile/api/types.ts)에 있어 단일 파일 = 단일 티켓 원칙에 따라 이 티켓이 이 파일의 추가 필드·인터페이스를 모두 소유한다(후행 api-fn·훅 티켓들의 공통 병목).

  • PostResponse/PostDetailResponse에 communityId?: number \| null, sportCategory?: SportCategory \| null 추가 (BE post-community TDD “API 계약”).
  • CreatePostRequest에 communityId?, sportCategory?, type 유지 확장.
  • CommentResponse는 존재 — 댓글 작성 요청 타입 CreateCommentRequest { content: string } 추가.
  • PostSearchQuery(criteria) 타입에 communityId?, sportCategory? 추가.
  • SlotResponse에 programId?: number \| null, status?: 'OPEN' \| 'CLOSED' 추가 (모집·시설상품 TDD).
  • ProgramResponse { id, facilityId, price, capacity, durationMinutes, name, description } 신규.
  • SportCategory 타입은 api/community-types.ts에서 재수출(import)해 사용 — 중복 정의 금지.

근거: 20260707-post-community-연동-tdd.md API 계약, 20260707-모집-시설상품-소모임예약연동-tdd.md REST API 계약, 20260707-...-design-fe-app.md “API 연동 표”.

의존

  • 없음 (wave 1)

다이어그램

클래스 의존

flowchart LR
    Types["api/types.ts (확장)"] --> SC["api/community-types.ts SportCategory"]
    PostFn["api/post.ts (FE-06)"] --> Types
    FacFn["api/facility.ts (FE-07)"] --> Types

테스트 케이스

  • 타입 컴파일: PostResponse에 communityId·sportCategory nullable 필드가 존재하고 tsc --noEmit 통과
  • CreatePostRequest에 communityId 미지정(전역)·지정(모임) 두 경우 모두 타입 오류 없이 구성된다
  • SlotResponse.status가 ‘OPEN’|‘CLOSED’ 리터럴 유니온으로 좁혀진다(임의 문자열 대입 시 타입 오류)
  • ProgramResponse의 price/capacity/durationMinutes가 number로 강제된다
  • SportCategory가 재정의가 아니라 community-types에서 import돼 값 12종이 단일 SSOT를 유지한다

그래프 뷰