TCA 기본 개념

Created

2024/02/16 14:31

TCA는 현재 상태가 어떤지 파악하고 이를 관리하기 쉽게 하기 위하여 고안된 단방향 아키텍쳐이다.

•

단방향 아키텍처로서 View가 ViewModel의 상태를 관찰하고 해당 상태에 따라 업데이트 된다.

•

View는 자기 자신을 렌더링하고 유지하기 위해 ViewModel에게 자신의 상태와 로직을 전달한다.

•

따라서 View는 그 상태와 로직이 어떤 방식으로 변형되는지 알지 못해야 한다.

•

그러나 SwiftUI와 같은 양방향 데이터 바인딩을 지원하는 프레임워크를 사용하면 View가 ViewModel에서의 요청을 받아와서 추가적인 작업을 해야 하는 경우가 발생한다.

•

이를 방지하기 위해 @Published 속성들에 대한 엄격한 캡슐화를 지향하는 사람들도 있으나, 일괄적인 가이드라인은 없는 상태

•

즉, 협업 중 코드 작성 시에 유의하지 않는다면, 나중에 언제 어디서 상태가 바뀌는지 알기 파악하기 어려운 문제를 야기한다.

→ 이와달리, TCA는 상태 변화에 대한 일괄적인 가이드라인을 컴파일 단계에서부터 확보한다.

→ 누구나! TCA를 적용한다면 상태 변화를 일 으키는 Action 정의, Action 에 대한 View 에서의 .send() 를 거쳐야 한다.

위 그림과 같이 TCA는 원래의 목적을 달성하기 위해 Single Source Of Truth(단일 진실 공급원)을 따르는 철저한 단방향 구조를 선택했다.

Single Source Of Truth는 애플리케이션의 상태나 데이터에 대한 유일한 출처를 가지는 것을 의미한다. 이로써 모든 상태 변경을 출처가 명확해지며, 그 변경이 예측, 추적 가능해지게 된다.

•

State

◦

변동을 추적하고 의도하지 않은 변경에서 지켜내야할 상태

•

사용자가 View를 통해 어떠한 작업이나 알림, 이벤트를 트리거 하면 연결된 Action 이 Reduce 내에 구현된 함수로 State 를 변화시키는 Effect를 반환 한다.

•

이때, 그 작업이 크게 복잡하지 않다면 바로 상태를 변화시킬 수도 있고, 때로는 네트워크 통신과 같은 비동기적인 작업이 필요한 경우가 있을 수 있다.

•

비동기적인 작업이 필요한 경우에는 통신을 실행하는데에 필요한 환경과 자원이 필요하고 이를 “의존성을 갖게 된다” 라고 표현한다.

•

또한 이때, 이 작업은 성공할 수도, 실패할 수도 있는데, 보통 성공한 경우를 Effect, 예상치 못한 경우를 Side Effect 라고 한다.

•

이렇게 도출된 Effect 에 따라 다시 Action 을 선택해 State 를 변경한다.

•

이렇게 변경된 State 는 다시 뷰에 영향을 주게 되는 흐름으로 TCA는 작동한다.

→ 이러한 단방향 흐름은 애플에서 제안하는 흐름과 일맥통하는 부분이 있다.

→ 그 이유는 TCA가 SwiftUI를 닮으려고 노력하기 때문!

•

body를 구현함으로써 Reducer 를 정의하거나, Dependency 를 프로퍼티 래퍼로써 사용하는 점과 같이 곳곳에서 그 흔적을 찾을 수 있다.

List view