feat(afternote): 추억 노트 상세 제목의 이름 표시 지연 제거 — 이미 있는 이름 캐시를 상세도 읽는다 #1497

작업 유형

enhancement — 신규 기능·기존 기능 개선

주 담당 모듈

afternote — 애프터노트

개요

추억 노트 상세 제목의 이름 세그먼트가 네트워크 왕복이 끝나야 채워진다. 진입 직후에는 추억 노트에 대한 기록 으로 그려졌다가, GET /users/me 응답이 도착하면 추억 노트에 대한 OO님의 기록 으로 제목 한 줄이 눈앞에서 다시 쓰인다.

원인은 상세 VM 이 이름을 매번 원격으로만 구하기 때문이다 — AfternoteDetailViewModel.init 이 userRepository.getMyProfile() 를 화면 진입마다 발사하고, UserRepositoryImpl.getMyProfile() 에는 캐싱이 없다.

그런데 같은 값의 로컬 캐시가 이미 있다.

홈이 콜드스타트 placeholder 로 쓰는 그 이름이 상세가 필요한 이름과 같은 값이다. feature:afternote 는 이미 UserProfileRepository 를 주입하고 있어(AfternoteHostViewModel 의 패스키 상태) DI 결선도 새로 필요 없다.

변경 — 홈이 쓰는 stale-while-revalidate 를 상세에도 적용한다.

1. init 에서 getCachedUserName() 을 먼저 읽어 표시명에 즉시 반영한다.
2. getMyProfile() 응답이 도착하면 화면을 갱신하고 saveUserName() 으로 캐시를 최신화한다.
3. 캐시가 비어 있고 조회도 실패하면 현행대로 이름 세그먼트를 생략한다 — 표시명은 장식 정보라 화면을 차단하지 않는다.

완료 조건

• 캐시에 이름이 있으면 상세 첫 프레임 제목에 이름이 들어간다 (네트워크 대기 없음).
• 서버 이름이 캐시와 다르면 도착 시 화면과 캐시 양쪽이 갱신된다.
• 캐시 읽기·쓰기 실패가 화면을 막지 않는다.
• 위 세 갈래를 유닛 테스트로 가둔다.

범위 밖 — UserRepository 인터페이스에 캐시 계약(myProfileFlow 류)을 새로 다는 일. 프로필 책임 분리가 #1282 에서 진행 중이라 계약을 늘리지 않고 이미 있는 캐시 API 만 소비한다.

자식 이슈

No response

참고

• chore(home): GetHomeSummary 가 호출하는 4개 Repository 의 캐싱 계층 점검 #248 (closed) 에서 getMyProfile 캐싱 부재를 점검하고 «후속 캐싱 도입은 별도 점검 이슈로 쪼개지 않고 각 Repository 자연 작업 PR 에 묻어 진행» 으로 닫았다. 이 이슈가 그 애프터노트 갈래의 실행분이다.
• UserRepository 17개 멤버를 수신자·프로필·계정·푸시 설정 책임으로 분리 #1282 · refactor(core): UserProfileRepository 를 실체(로컬 캐시)가 드러나는 이름으로 — MyProfileRepository 와 한 글자 차이 #1433 이 UserRepository 분리와 UserProfileRepository 개명을 다루고 있어, 본 작업은 인터페이스를 늘리지 않는다.
• 추억 노트 상세 시안 결손 — 하단 고지·영상 재생·오버레이·타이틀 개행 #463 은 같은 제목 줄을 다루지만 시안 결손(타이틀 개행 등) 이라 성격이 다르다.
• 착지점은 fix(afternote): 상세·수신자 화면이 재진입 시 데이터를 다시 조회한다 (#701) #1374 에서 이미 마련됐다 — 표시명이 AfternoteDetailUiState.Success.authorDisplayName 으로 분리돼 있어 캐시 값을 그 자리에 그대로 실으면 된다. 그래서 이 작업의 PR 은 fix(afternote): 상세·수신자 화면이 재진입 시 데이터를 다시 조회한다 (#701) #1374 위에 스택으로 쌓는다.
• 설정에서 이름을 바꾸면 캐시가 한 박자 낡지만, 이 변경 자체가 상세 진입마다 캐시를 다시 쓰므로 자가 치유된다.