프롬앱에 TCA 적용하기

들어가며

안녕하세요. 모바일팀에서 iOS앱 개발을 맡고 있는 정김기보입니다.

최근 fromm iOS앱은 더 큰 서비스로의 성장을 위해 리팩토링을 진행하고 있습니다. 리팩토링을 진행하며 일부 화면들은 SwiftUI로의 변환을 시도하고 있는데요. 그러면서 SwiftUI와 MVVM이 어울리지 않는다는 내용들을 많이 접하게 되었고 대안으로 자주 언급되는 TCA를 도입해보기로 하였습니다. 그래서 이번 글에서는 간단하게 TCA를 적용하며 느낀점들을 공유해보도록 하겠습니다.

TCA란?

상태 관리 기반의 단방향 아키텍쳐로 MVI, ReactorKit과 비슷한 아키텍쳐입니다.

동작하는 모습을 정말 간단하게 표현하면 아래와 같습니다.

1. View에서는 ViewAction을 통해 스토어에 Action을 전달합니다.
2. Action에 따라 Reducer는 Effect를 발생시키고 State를 업데이트합니다
3. Effect는 다시 Action을 만들어내고 이 액션은 다시 Reducer에 전달됩니다
4. State는 ViewState로 변환되어 View의 UI를 업데이트합니다
5. 2-4번 과정을 Effect가 없을 때가지 반복합니다.

기존 ViewModel

기존 fromm에서는 MVVM 구조와 Stateful UI를 활용하여 앱을 만들었습니다. 구현된 ViewModel은 아래와 같습니다

protocol ViewModelType {

    associatedtype State

    associatedtype Event

    associatedtype Input

    func through(_ input: Input)

    var event: PassthroughSubject<Event, Never> { get }

    var state: State { get }
}

간략하게 설명을 드리면 State를 유지하며 through함수를 통해 Input을 처리하여 State를 바꾸어주거나 Event를 내보내고 있는 형태입니다.

기존 ViewModel과 Store의 차이점

여러 차이점이 있겠지만 오늘 설명드리고 싶은 부분은 Reducer는 작은 Reducer들의 합성으로 표현이 가능하지만 기존 ViewModel은 작은 ViewModel들로의 합성이 불가능하다는 것입니다.

아래 채팅방 설정 예시를 통해서 차이점을 살펴보겠습니다.

위 기능은 현재 아래 방식대로 구현되어 있었습니다.

final class ChatRoomSettingViewModel: ViewModelType {
   struct State {
      let nickname: String
      let roomName: String
   }
   
   ...
   
   func through(_ input: AnyPublisher<Input, Never>) {
      input.sink { [weak self] action in 
         switch action {
         case .viewDidLoad:
            ...
            self.chatManager.currentRoom
               .sink { ... 
                   self.state.nickname = room.nickname // 1 & 3
               }
            ...
         }
      }
   }
}

final class ChatRoomNicknameViewModel: ViewModelType {   
   struct State {
      let nickname: String
   }
   ...
   let updateNicknameUsecase: UpdateNicknameUseCase
   
   func through(_ input: AnyPublisher<Input, Never>) {
      input.sink { [weak self] action in 
         switch action {
		 case .changeNickname(let nickname):
		    self?.updateNickname(nickname)
         }
      }
   }
   private func updateNickname(_ nickname: String) {
      updateNicknameUsecase.execute(nickname)
      .sink { ...
         self.chatMananger.updateNickname(nickname) // 2
      }
   }
}

현재 동작을 보면 아래와 같이 동작합니다.

1. 부모 뷰에서 화면 진입 시 데이터를 공통으로 관리하고 있는 곳에서 닉네임을 가져오고 있음
2. 자식 뷰에서 닉네임을 바꾸고 공통으로 관리하고 있는 곳을 업데이트 함
3. 부모 뷰에서 해당 이벤트를 감지하여 바뀐 방의 닉네임을 가져옴

위 기능을 TCA를 활용하면 아래와 같이 구현할 수 있습니다.

리듀서부분

// 채팅방 설정의 비즈니스 로직을 가지고 있는 리듀서
public struct ChatRoomSettingFeature: Reducer {
   public struct State {
      public var nickname: NicknameFeature.State(nickname: String)
      public var roomName: RoomNameFeature.State(roomName: String)
      ...
      
      public init(chatRoom: ChatRoom) {
         nickname = .init(nickname: chatRoom.nickname)
         ...
      }  

   public enum Action {
      case nickname(ChatRoomEditNicknameFeature.Action)
	  ...
   }

   public var body: some Reducer<State, Action> {
      Reduce { state, action in
         switch action {
         default:
            return .none
         }
      }

      Scope(state: \.nickname, action: /Action.nickname) {
         NicknameFeature()
      }
	  ...
   }
}

// 애칭 변경의 비즈니스 로직을 가지고 있는 리듀서
public struct NicknameFeature: Reducer {
   public struct State {
      var editedNickname: String
      var isChanged: Bool = false
      var nickname: String
      
      public init(nickname: String) {
         self.nickname = nickname
         self.editedNickname = nickname
      }
   }
   public enum Action {
      case nicknameChanged(String)
      case onAppear
      case saveButtonTapped
      case setNicknameResponse<TaskResult<SetNicknameResponse>>
   }
   ...
   public var body: some Reducer<State, Action> {
      Reduce { state, action in 
         switch action {
         case let .nicknameChanged(changed):
            state.editedNickname = changed
         ...
         case let .setNicknameResponse(.success(response)):
            state.nickname = state.editedNickname
            state.isChanged = false
            return .none
         ...
         }
      }
   }
}

UIViewController부분

...
import ComposableArchitecture

// 채팅방 설정의 화면에 해당하는 UIViewController
public final class ChatRoomSettingViewController: UIViewController {
   let store: StoreOf<ChatRoomSettingFeature>
   let viewStore: ViewStore<ViewState, ViewAction>
   ...
   
   struct ViewState: Equatable {
      ...
      init(state: ChatRoomSettingFeature.State) {
         // 여기서 Reducer의 Domain모델에서의 ViewModel로의 전환을 합니다
      }
   }
   
   enum ViewAction {
      // 이 뷰에서 입력받을 액션들을 정의합니다
   }
   
   public init(store: StoreOf<ChatRoomSettingFeature>) {
      self.store = store
      self.viewStore = ViewStore(
         store, 
         observe: ViewState.init, 
         send: ChatRoomSettingFeature.Action.init
      )
      ...
   }
}

// 애칭 변경 화면에 해당하는 UIViewController
public final class NicknameViewController: UIViewController {
   let store: StoreOf<NicknameFeature>
   // 위와 동일
   ...
}

ChatRoomSettingFeature의 State와 Action을 보면 NicknameFeature의 State와 Action같은 더 작은 리듀서들의 State의 조합으로 이루어진 것을 볼 수 있습니다.

기존과 비교해 가장 두드러진 차이점으로는 기존에는 “채팅방 설정화면”에서 애칭을 최신으로 유지하는 것의 책임이 부모의 ViewModel에 있었다면 지금은 “자식 Reducer와 애칭을 공유하고 있기 때문에 해당 책임이 사라진 것”입니다.

이제 채팅방 설정 도메인에서 애칭과 관련된 로직은 한 곳에만 유지되고 있음을 확인할 수 있습니다. 추후 애칭과 관련된 로직을 변경하거나 추가할 때 가정 적합한 곳은 어디인가?에 대한 질문을 하게 된다면 쉽게 NicknameFeature라고 예측하거나 팀원들의 동의를 얻기 쉬울 것 같다는 생각이 듭니다.

두 구조의 차이점을 정리하자면

• 자식과 부모간에 데이터 공유가 보다 수월해졌다
• 데이터 변경이 일어나는 곳이 한정되었으며 예측이 쉽다

마치며

지금까지 간단하게 저희 앱의 리팩토링 과정에서 적용된 TCA 예제를 통해 이점에 대해서 확인해보았습니다. 부족한 내용이기에 PointFree 홈페이지의 강의를 듣거나 Github에 제공되는 예제를 통해 더욱 자세한 내용을 확인하시기를 권장드리는바입니다!

추후 더 많은 곳에 적용하게 되면 기존 아키텍쳐에서 TCA로 변환하는 더 자세한 과정과 이점에 대해서도 한 번 더 소개드릴 수 있기를 바랍니다.