Coordinator 리팩토링

[Monfi98]

배경

이 PR을 구현을 하다가 보니 고민이 생겼고, 이를 해결하기 위한 방안을 제시하기 위해 이 Discussion을 열었습니다. 초기에 구상한 구조는 아래와 같지만 아직 결정이 안난 사안이기 때문에 카톡방에서 얘기를 나눈대로 Onboarding 과 Main 두 개의 Coordinator로 통합해 두었습니다.

통합한 형태로 작업을 이어가다 보니 ViewModel 관리(생명주기)에 대한 구조적인 문제와 마주치게 되었습니다.

우리가 원하는 것

ViewModel을 사용하는 뷰가 소멸하면 해당 ViewModel도 함께 소멸되어야 하고,
필요할 때는 동일한 ViewModel 인스턴스를 여러 화면에서 안전하게 공유할 수 있어야 한다.

현재 문제

통합된 coordinator 내에서 ViewModel 관리를 해야하다 보니 MainCoordinator의 생명주기와 같거나,
해당 ViewModel이 필요한 뷰가 push 될때마다 새로운 ViewModel을 생성해야한다.

해결 방안

따라서, Feature 단위로 Coordinator를 나누는 해결방안을 제시합니다.

저희 앱에서는 다른 탭이지만 같은 화면으로 이동하는 로직들이 여러가지 있습니다. (홈화면 → 도서 정보 조회, 검색 → 도서 정보 조회 등등) 각 Coordinator가 Feature 단위로 ViewModel의 생명주기를 책임지고 관리하도록 하면, 공통 화면에서의 재사용성과 ViewModel의 일관성을 유지할 수 있을 것 같습니다.(+ Route 중복 해결)

이러한 구조를 적용하면, 해당 Flow가 유지되는 동안 ViewModel 인스턴스도 함께 유지되며, Flow가 종료되면 ViewModel 역시 자연스럽게 소멸되도록 관리할 수 있을 것 같습니다.

해당 의견에 대해서 자유롭게 달아주세요!

[Syrbear]

같은 화면에 대해 ViewModel의 공유가 이해가 가지않습니다!
플로우상 특정 화면을 넘어가면서(push) 뷰모델이 생성이 되면 뒤로가기(pop)를 하기 되면 뷰모델이 자연스럽게 소멸된다고 생각합니다

예를 들어) 메인 화면에서 최근 업데이트한 독서 기록을 눌러서 조회 화면으로 넘어갔다면, 다른 화면으로 이동 하기 위해서는 뒤로가기를 눌러야하니 이때 조회화면에서 나가면 해당 뷰모델이 소멸될거라 생각합니다

혹시 이런부분에서 말고 뷰모델이 공유가 되어야하는 부분이 있는건가요?

[Monfi98]

View와 ViewModel이 일대일 대응인 상황에서는 근웅님이 생각이 맞습니다!
하지만 현재 저희 앱에서는 마이페이뷰, 닉네임 입력뷰, 카테고리 선택뷰는 같은 SettingViewModel을 사용하고 있습니다.
(이외에도 도연님 뷰에서 SearchViewModel을 2개 이상의 뷰에서 가지구 있구여)

좀더 구체적으로 제가 구현해야하는 상황에 대해서 말해보겠습니다.
SettigViewModel은 두 가지 feature에 따라 ViewModel이 생성/소멸이 되어야합니다.

1. OnBoarding Feature -> NicknameView(생성) -> CategorySelectionView(소멸)
2. MyPage Feature -> MyPageView(생성) -> NicknameView or CategorySelectionView -> 다른 탭으로 이동(소멸)

따라서, NicknameView 관점에서 보시면 SettingViewModel을 외부에서 주입해야합니다.
(생성할수도, 넘겨받아야할 수도 있어야하니까)

[Syrbear]

아! 이해했습니다. 제가 뷰랑 화면을 동일시해서 이해를 못하고 있었던거네요!!
그럼 코디네이터를 각 기능의 루트(온보딩, 마이페이지) 마다 두고 해당 코디네이터에서 뷰모델을 가지고 있는 상태(StateObject)이고, 뷰를 띄울때 마다 해당 뷰모델을 주입(ObservedObject)하면 관리가 가능해지신다는 말씀이겠네요.

그럼 이전에 얘기를 나누었던 방안2번이 해당 방식이 맞을까요?

추가로 궁금한 것이 코디네이터를 나눔으로써 해결할 수 있는 문제인 것은 인지했습니다만, 뷰모델을 나눔으로써 해결할 수 있지 않을까 하는 생각이 듭니다.
뷰모델이 아닌 코디네이터를 나눔으로써 해결하는 쪽으로 선택이 된다면, 해당 방안이 유지 보수가 더 쉽게 가능해서인가요?(개발비용문제) 아니면 뷰모델을 나누는 방식보단 코디네이터를 나누는 방안이 더 좋은 방안인가요?(정석적인 해결방안)

[Monfi98]

해당 방법은 정석 보다는 "우리 상황에 맞는 방법"이 더 가까운 것 같습니다.
저희 앱에서는 이미 하나의 뷰모델을 여러 뷰가 가지고 있는 상황이고, 이것을 일부러 쪼개서 1대1 대응으로 만든다는 것은 비효율적이라고 생각됩니다.
이미 개발 당시에 여러 뷰에서 동일한 기능 혹은 유사한 성격의 상태와 로직을 공유한다고 판단하고 개발을 했기 때문에 현재 상태처럼 되었을 텐데,
지금 시점에서 뷰마다 쪼개버리게 된다면, 공통된 로직이 분산되면서 유지보수가 더 힘들어질 것 같습니다.