Repository navigation
refactor(setting): MVI 전환 — setting·timeletter 몫 총괄 #1813
Description
작업 유형
refactor — 동작 변경 없는 구조·책임·경계 개선
주 담당 모듈
setting — 설정
개요
MVI 전환(#1811) 중 setting·timeletter 담당 몫을 묶는다.
자식
| 이슈 | 대상 | 규모 |
|---|---|---|
| #1805 | setting | VM 11개 · Screen 17개 · on* 콜백 88개(레포 최다) · @Test 46개 · Channel 5개 |
| #1806 | timeletter | VM 7개 · Screen 7개 · on* 콜백 45개 · @Test 20개 |
착수 조건
- refactor(core): MVI 베이스 MviViewModel 신설 — Intent/ReducerEvent/Effect 4타입 계약 #1800(
MviViewModel베이스) 과 refactor(onboarding): MVI 전환 파일럿 — ViewModel 3개 + 신호 소비를 Intent 로 #1802(onboarding 파일럿에서 관용구 확정) 이후에 착수한다. 관계로 걸려 있다. - setting 은 일회성 이벤트를 이미
Channel로 처리하는 유일한 모듈이라(5개 VM) 전환 비용이 다른 모듈보다 낮다.
이 역할이 먼저 정리하는 편이 나은 것
두 모듈 모두 Navigation 3 이관이 병행 중이라 같은 파일을 건드린다.
- setting — refactor(setting): 설정 흐름을 Navigation 3 로컬 스택으로 이관 #1695(Nav3 로컬 스택 이관) · TimeLetter 단순 back 위임 5개를 공통 명령으로 통합 #1301(단순 back 위임 15개 통합)
- timeletter — refactor(timeletter): 타임레터 흐름을 Navigation 3 로컬 스택으로 이관 #1696(Nav3 로컬 스택 이관) · TimeLetter 단순 back 위임 5개를 공통 명령으로 통합 #1301(단순 back 위임 5개 통합)
Nav3 이관을 먼저 끝내는 편이 충돌이 적다. 순서는 담당자가 정한다.
Activity
OnlyReadOneBook commentedon Sep 13, 2026
총괄 실측 (2026-09-13,
origin/develop7d87aa3)이 이슈로 쓸 코드는 0줄이고 진행률은 자식 #1805 · #1806 이 낸다. 착수 조건과 자식 상태를 develop 실코드로 다시 재봤다. 본문 표와 어긋난 곳도 아래에 적는다. 본문은 손대지 않는다.
착수 조건 1. #1800 (MviViewModel 베이스): 채워졌다
산출물이 develop 에 실재한다.
core/ui/src/main/kotlin/com/afternote/core/ui/mvi/MviContract.ktMviIntent24,UiState31,ReducerEvent41core/ui/src/main/kotlin/com/afternote/core/ui/mvi/MviViewModel.ktabstract class47,onIntent66,reduce74core/ui/src/main/kotlin/com/afternote/core/ui/mvi/ObserveSignal.kt@Composable fun ObserveSignal42docs/convention/mvi.mdkonsist/src/test/kotlin/com/afternote/konsist/MviContractKonsistTest.kt본문은 이 몫을 #1800 하나로 적었지만, 문서와 konsist 가드는 #1801 이 세웠다(PR #1823, 2026-09-07 머지). #1800 · #1801 둘 다 CLOSED 라 조건 자체는 걸리지 않는다. 이 이슈의 blocked_by 에 남은 것은 #1802 하나다.
착수 조건 2. #1802 (온보딩 파일럿): 안 채워졌다
#1802 는 OPEN 이고 PR #1825 가 열려 있다. #1825 의 base 가 develop 이 아니라
refactor/1863-onboarding-failure라, #1802 를 막고 있는 #1863 이 먼저 들어가야 한다. 관용구가 develop 에 확정되는 시점은 그 뒤다.develop 실코드: 18개 전부 미전환
setting 11 + timeletter 7 = 18개 ViewModel 이 모두
: ViewModel()이다.feature/아래MviViewModel참조는 0건이다.konsist allowlist 도 그대로다.
ISSUE_1805_SETTING11개.MviContractKonsistTest.kt:438, 항목은 440-450ISSUE_1806_TIMELETTER7개. 같은 파일 454, 항목은 456-462PENDING_MVI_MIGRATION전체 51개(:471) 중 이 이슈 몫이 18개자식 #1805 (setting): 본문 표와 범위가 다르다
본문 표는 "VM 11개" 로 적혀 있는데, #1805 는
ReceiverListViewModel하나로 좁혀졌고 나머지는 다른 이슈·PR 이 가져갔다. allowlist 11줄의 현재 임자는 이렇다.codex/1695-setting-nav3refactor/1502-setting-state-mvirefactor/1502-setting-state-mvirefactor/1502-setting-state-mvidevelop11개 전부 열린 PR 에 임자가 있고, develop 에 닿은 것은 0개다. #1805 의 blocked_by 가 비어 있는 것도 이 재분배와 맞는다. 남은 독립 범위가 #1502 · #1802 의 소비처와 겹치지 않아서다.
자식 #1806 (timeletter): 착수 전
PR 이 없다. blocked_by 에 #1802 가 그대로 있다. 같은 파일을 건드리는 열린 PR 은 #1905(#1921 재진입 갱신)와 #1365(#714 실패 상태) 둘인데, 두 PR 의 diff 에
MviViewModel이 0건이라 전환분이 아니라 충돌면이다. allowlist 7줄은 아무도 빼지 않는다.Nav3 선행 정리: setting 쪽은 스택이 순서를 이미 정했다
본문은 "순서는 담당자가 정한다" 로 열어 뒀는데, setting 은 PR 스택이 Nav3 를 맨 밑에 깔아 답을 냈다.
setting MVI PR 4개가 전부 draft 인 #1962 위에 얹혀 있다. #1962 가 draft 를 벗고 들어가기 전에는 위의 것들이 develop 에 못 닿는다. timeletter 쪽 #1696 · #1301 은 열린 PR 이 없어 순서가 아직 미정이다.
남은 것
PENDING_MVI_MIGRATION에서 setting 11 · timeletter 7 이 빠진다. 전체 종료 판정은 refactor(platform): 최종 앱 루트 책임 판정과 MVI 전환 종료 검사 (#1809 분리) #2022 가 본다.본문 표의 "#1805 setting VM 11개" 는 지금 범위와 맞지 않는다. 고쳐 쓰려면 담당자가 본문을 바꾸는 편이 낫겠다.
OnlyReadOneBook commentedon Sep 23, 2026
총괄 이슈를 두지 않기로 정리하면서 닫습니다(2026-09-23). 남은 전환은 하위 이슈가 각자 진행합니다.