[sangYuLv]

JIRA

📝 작업 내용

📌 요약

• 약속 저장소를 약속 문서 / 참여자 경로 두 개로 재편 (async/await 전환)
• 약속 날짜 필수화 — 생성 화면은 다음 정시로 미리 채움, 카드의 날짜 "미정" 표시 제거
• 약속 API 연결 전 Firestore 구조와 작업 순서 확정 (리뷰 노트 참고)

🔍 상세

[1] 약속 Repository 재편
기존 AppointmentCreationRepository / AppointmentDetailRepository / AppointmentInfoRepository 3개를 삭제하고, Firestore 문서 단위에 맞춰 2개로 나눴습니다.

• AppointmentRepository: 약속 문서 — 생성, 코드로 참여, 조회, 정보 수정
• AppointmentRouteRepository: 참여자별 경로 조회 (routes 하위 컬렉션 대응)
• Repository와 약속 UseCase 5개를 completion → async throws로 전환, ViewModel은 Task { @MainActor }에서 호출

[2] Appointment 엔티티 정리

• placeVoteStatus 제거 — Mock 외 사용처 없음. 투표는 공유 장소 쪽(voterIDs)에서 다룰 예정
• routes 제거 — 경로는 AppointmentRouteRepository에서 따로 조회
• GetAppointmentDetailUseCase: 약속과 경로를 함께 조회해 합치고, 현재 사용자 ID는 AuthRepository에서 가져옴 (로그인 정보 없으면 notAuthenticated)

[3] Mock 정리

• MockAppointmentRepository, MockAppointmentRouteRepository로 통합
• 약속 정보 화면도 경로 지도와 같은 Mock 약속(참여자 6명)을 보여주도록 변경 — 기존 "강남역 모임"(3명) Mock은 삭제
• Mock 참여자의 "나"는 로그인한 사용자 ID로 채움

[4] 약속 날짜 필수화
엔티티에서 약속 필드가 옵셔널 타입이 아닌 상태여서 다시 검토해봤습니다.
날짜가 옵셔널이면 약속 목록에서 정렬하기 어렵기도 하고, 약속 생성 시에 초기 날짜 데이터를 설정해두는 방향도 괜찮겠다고 판단했습니다.

1. 약속 만들기 화면: 진입 시 날짜를 다음 정시로 미리 채움, 생성하기 버튼은 항상 활성
2. 표시 모델 (AppointmentInfo, UpcomingAppointment, AppointmentListItem): date를 Date로 변경
3. 카드 5곳 (홈, 약속 목록, 마이페이지 알림, 약속 정보, 생성 확인): 날짜 "미정" 표시 제거 — 장소 "미정"은 유지
4. 목록 정렬 3곳: distantFuture / distantPast 대체값 제거

💬 리뷰 노트

약속 Firestore 구조

약속 API를 연결하기 전에 문서 구조를 먼저 확정했습니다. 이번 PR의 Repository 재편도 이 구조를 기준으로 했습니다.

appointments/{appointmentID}           자동 생성 ID
  name, code, dateTime(필수), place(Map?), participantIDs
appointments/{id}/routes/{userID}      departureTime, arrivalTime, totalDistance, steps
appointments/{id}/chats/{chatID}       채팅 전환 때 상세 결정
appointments/{id}/sharedPlaces/{id}    voterIDs, 공유 장소 전환 때 상세 결정
users/{userID}.appointmentsNotification  기존 유지 (약속별 알림)

• participants는 문서에 participantIDs로만 두고, 조회할 때 users를 in 질의로 채웁니다.
• 경로는 약속 문서에 넣지 않고 routes/{userID} 하위 컬렉션으로 분리했습니다. 참여자마다 자기 경로만 쓰기 때문에 문서 하나를 여러 명이 동시에 수정하지 않도록 했습니다.

서버(Functions)와 클라이언트의 처리 범위

동작	처리 위치	이유
생성 (createAppointment)	Functions callable	고유 코드 생성 보장
참여 (joinAppointment(code))	Functions callable	참여 전 사용자가 약속 문서를 읽지 못하게 하기 위함
나가기 (leaveAppointment)	Functions callable	마지막 참여자면 recursiveDelete로 약속 문서 + 하위 컬렉션 삭제
조회 · 정보 수정 · 내 경로 저장	클라이언트 직접	보안 규칙으로 참여자만 허용

Repository 구성과 실시간 리스너 위치

• Repository는 Firestore 문서 단위로 나눴습니다. 화면 단위(생성/상세/정보)로 나뉘어 있으면 같은 문서를 다루는 코드가 여러 곳에 흩어지기 때문입니다.
• 이번 PR에는 지금 호출하는 곳이 있는 메서드만 넣었습니다. 아래 메서드는 연결하는 PR에서 추가할 예정입니다.
  • leaveAppointment, fetchMyAppointments(from:to:) (목록 4곳 공용), observeAppointment → AnyPublisher, saveMyRoute
• 실시간 리스너는 채팅방에만 둘 예정입니다.
  • 목록 4곳: viewWillAppear마다 1회 조회
  • 경로 지도: 1회 조회 (실시간 위치는 RTDB에서 별도 처리)

약속 날짜 필수화

날짜 없는 약속은 목록 정렬과 라이브 액티비티 같은 시간 기반 기능에서 계속 예외 처리를 만들어서, 문서 단계에서 필수로 정했습니다.

• 생성 화면은 버튼을 비활성화하는 대신 다음 정시를 미리 채우는 방식을 택했습니다.
• 정보 수정 쪽의 date: Date?는 "변경하지 않음"이라는 의미라 그대로 두었습니다.

추후 작업

약속 API 연결은 아래 순서로 PR을 나눌 예정입니다.

1. 약속 생성 · 참여 · 나가기 Cloud Functions 구현 및 연동
   • Functions를 조회보다 먼저 붙여서, 조회 작업 때 앱으로 실제 데이터를 만들 수 있게 합니다.
   • 이 PR 동안은 생성·참여 후 화면에 Mock 조회 결과가 보이는 상태입니다.
2. 약속 조회 · 정보 수정 Firestore 연동 — DTO, 목록 4곳 연결, 보안 규칙(참여자만 읽기/쓰기)
3. 채팅방 실시간 리스너 → 알림 → 내 경로 저장 (길찾기 API 연동 이후)

[snughnu]

Repository 재편 내용과 약속 날짜 필수값 둘 다 괜찮은 것 같습니다 ~ !
리뷰 노트 내용도 확인했어요 수고하셨습니다. 🙊