refactor(afternote): 에디터 미디어 삭제 진입점을 set*(null) 에서 떼고 미디어 콜백을 non-null 로 조인다 (#1561 후속) #1717

작업 유형

refactor — 동작 변경 없는 구조·책임·경계 개선

주 담당 모듈

afternote — 애프터노트

개요

#1561(PR #1565)에서 추모 영상 값 객체는 교체와 취소를 withSelection(url: String) / discardSelection() 두 연산으로 갈랐다. 그런데 값 객체 위의 사슬은 여전히 null 하나로 두 동작을 겸한다. 사진 쪽도 같은 모양이다.

• AfternoteEditorContent L126-L127 — 시트의 삭제 항목이 setMemorialPhoto(null) / setMemorialVideo(null) 로 배선된다.
• AfternoteEditorViewModel L222-L224 — setMemorialPhoto(uri: String?), setMemorialVideo(url: String?), setMemorialThumbnail(dataUrl: String?).
• AfternoteEditorState L44-L46 — 콜백 타입이 전부 (String?) -> Unit.
• EditorFormMutations — withMemorialVideo(url: String?) 가 null 을 discardSelection() 으로 갈라 주는 유일한 자리. withMemorialThumbnail(url: String?) 은 null 이면 no-op.

왜 문제인가.

• ViewModel 의 공개 API 만 보면 «삭제» 가 존재한다는 사실이 안 보인다. setMemorialVideo 의 본문과 KDoc 을 읽어야 null 이 삭제인 줄 안다.
• setMemorialThumbnail(String?) 은 아무도 null 을 보내지 않는다 — AfternoteEditorRoute 가 pendingThumbnailUrl != null 가드 뒤에서만 부른다. 타입이 실제보다 넓어 호출부마다 «null 이면?» 을 생각하게 만든다.
• feat(afternote): 수정 모드에서 서버 영정사진·추모 영상을 지울 수 있게 한다 — BE 삭제 계약 확장 반영 #1597 이 들어오면 null 의 뜻이 «표시된 층 하나 걷기(교체분이면 서버로 복귀, 서버면 PATCH null)» 로 깊어진다. 그 3상태 의미를 null 한 값에 계속 실으면 값 객체가 굳이 갈라 둔 연산이 사슬 위에서 도로 뭉개진다.

완료 조건.

• AfternoteEditorViewModel 과 AfternoteEditorState 가 삭제를 이름 있는 연산으로 낸다 — removeMemorialPhoto() / removeMemorialVideo(). setMemorialPhoto·setMemorialVideo·setMemorialThumbnail 은 String 을 받는다.
• AfternoteEditorContent 의 onPhotoRemoved / onVideoRemoved 가 그 연산으로 배선된다.
• EditorFormMutations 에서 null 을 해석하는 분기가 사라진다. «삭제가 무엇을 하는가» 는 feat(afternote): 수정 모드에서 서버 영정사진·추모 영상을 지울 수 있게 한다 — BE 삭제 계약 확장 반영 #1597 이 정한 규칙 그대로 두고, 그 규칙을 부르는 이름만 바꾼다 — 동작 변경 없음.
• 기존 회귀 테스트가 그대로 통과한다. 옮길 호출부는 setMemorialVideo(null) 3곳(AfternoteEditorMemorialMediaRemoveTest·AfternoteEditorReceiverSnapshotTest), withMemorialVideo(null) 4곳(MemorialVideoServerOriginTest), 사진 쪽 setMemorialPhoto(null) 사용처.

자식 이슈

No response

참고

• 선행 세 건이 같은 진입점을 건드린다. 전부 머지된 뒤 착수한다.
  • refactor(afternote): 추모 영상·썸네일을 값 객체로 묶고 picked/server 축을 사진과 대칭으로 (#1406 후속) #1561 (PR refactor(afternote): 추모 영상 편집 상태를 값 객체로 캡슐화한다 (#1561) #1565) — 값 객체가 discardSelection() 을 갖게 되는 원점. 이 이슈는 그 후속이다.
  • fix(afternote): 추모 영상 썸네일 실패에 재시도 수단이 없다 — 결손이 저장으로 영구 확정된다 (#705 5번 분리) #1550 (PR fix(afternote): 추모 영상 썸네일 실패에 재시도 수단을 준다 (#1550) #1567) — setMemorialVideo 본문에 썸네일 재시도 상태 초기화를 얹는다.
  • feat(afternote): 수정 모드에서 서버 영정사진·추모 영상을 지울 수 있게 한다 — BE 삭제 계약 확장 반영 #1597 (PR feat(afternote): 수정 모드에서 서버 영정사진·추모 영상을 지울 수 있게 한다 (#1597) #1620) — withMemorialPhoto / withMemorialVideo 의 null 분기를 3상태로 넓힌다. 이 이슈는 그 분기의 이름 만 바꾸므로 feat(afternote): 수정 모드에서 서버 영정사진·추모 영상을 지울 수 있게 한다 — BE 삭제 계약 확장 반영 #1597 의 규칙이 확정된 뒤에 얹어야 두 번 손대지 않는다.
• null 삭제 배선의 출처는 영정사진·장례식 영상 첨부를 지우는 수단이 없다 — 잘못 붙이면 작성을 버려야 되돌아간다 #1114 (PR feat(afternote): 추억 노트 영정사진·영상 소스 시트에 삭제 항목 추가 (#1114) #1375). 당시 폼이 videoUrl: String? 한 칸이라 삭제가 그 칸을 비우는 것이었고, 그 시그니처가 값 객체 도입 뒤에도 남았다.