[SwiftUI] SwiftUI + TCA : Redux 패턴 영향? 단방향?

🧘 시작하기 전에…

TCA를 시작하기 전에 자주 언급되는 개념들이 있습니다.

Redux 패턴의 영향을 받았다, 단방향 아키텍처를 따른다 등인데, 처음 접하면 이런 용어들이 오히려 이해를 방해할 수도 있습니다.

그래서 먼저 이 개념들을 간단히 정리한 후, 본격적으로 TCA에 대해 알아보도록 하겠습니다!

---

🔍 TCA가 Redux 패턴에서 영향을 받은 핵심 원칙

TCA는 Redux 패턴에서 영향을 받아 "단일 상태(Single State)와 순수 함수 기반의 액션 처리(Pure Function Action Handling)" 를 따릅니다.

지금부터 이게 무슨 의미인지 하나씩 쉽게 풀어서 설명해볼게요.

---

1️⃣ 단일 상태(Single State)란?

👉 앱의 모든 상태(State)를 하나의 struct 안에서 관리한다.

이 말은 앱 전체의 데이터(상태)가 단 하나의 구조체로 표현된다는 것 을 의미합니다.

즉, "여러 개의 뷰(View)나 컴포넌트가 각자 상태를 가지지 않고, 하나의 중앙 상태에서 관리된다" 라는 개념이에요.

🔹 기존 방식 (SwiftUI @State)

기존 SwiftUI에서는 뷰마다 @State 변수를 선언하여 상태를 관리합니다.

struct CounterView: View {
    @State private var count: Int = 0

    var body: some View {
        VStack {
            Text("\\(count)")
            Button("증가") { count += 1 }
        }
    }
}

• CounterView 내부에서 count 상태를 관리함.
• 하지만, 만약 다른 화면에서도 count를 공유해야 할 경우, @State를 @StateObject나 @EnvironmentObject로 바꿔야 하는 불편함.

---

🔹 TCA 방식 (Single State)

TCA에서는 앱의 모든 상태를 State 라는 단일 구조체에서 관리합니다.

struct CounterFeature: Reducer {
    struct State: Equatable {
        var count: Int = 0
    }
}

• count 상태는 더 이상 View 안에 존재하지 않고, State 구조체 안에서 관리됨.
• 즉, 앱 전체가 단 하나의 상태(State)로 표현됨.
• 덕분에 여러 화면에서 같은 상태를 쉽게 공유하고 관리할 수 있음.

➡ "앱의 모든 데이터는 한 곳에서 관리된다!"

➡ "어디서든 같은 데이터를 쉽게 참조하고 변경할 수 있다!"

---

2️⃣ 순수 함수(Pure Function) 기반의 액션 처리

👉 모든 상태(State) 변경은 순수 함수(Pure Function)인 Reducer에서만 처리한다.

👉 즉, Reducer 내부에서만 State를 변경할 수 있고, 다른 곳에서는 상태를 직접 수정할 수 없다.

💡 순수 함수란?

같은 입력(State + Action)이 들어오면 항상 같은 출력(State)이 나오는 함수부수효과(Side Effect)가 없음
⇒ 네트워크 요청, DB 저장 같은 작업을 하지 않음

🔹 SwiftUI에서 직접 상태를 변경하는 방식

기본 SwiftUI에서는 상태를 직접 변경할 수 있습니다.

struct CounterView: View {
    @State private var count: Int = 0

    var body: some View {
        VStack {
            Text("\\(count)")
            Button("증가") {
                count += 1  // 직접 상태를 변경
            }
        }
    }
}

• Button을 누르면 count += 1 이 실행되면서 상태가 즉시 변경됨.
• 하지만 상태가 여러 곳에서 수정될 경우 예측하기 어려워지며, 디버깅이 어렵고, 상태 변경 로직이 분산됨.

---

🔹 TCA 방식 (Reducer에서만 상태를 변경)

TCA에서는 상태를 직접 변경하지 않고, Reducer를 통해서만 변경 해야 합니다.

struct CounterFeature: Reducer {
    struct State: Equatable {
        var count: Int = 0
    }
    
    enum Action: Equatable {
        case increment
    }
    
    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .increment:
                state.count += 1  // 상태 변경
                return .none
            }
        }
    }
}

💡 Reducer의 원칙

1. 입력이 같으면 항상 같은 결과를 반환해야 한다.
   • state.count += 1 은 같은 Action.increment 가 들어오면 항상 같은 동작을 수행함.
2. Reducer 내부에서만 State를 변경할 수 있다.
   • View에서는 state.count += 1 같은 코드를 직접 실행할 수 없음.
3. Side Effect(부수효과) 없이 상태 변경만 담당한다.
   • API 요청 같은 작업은 Effect를 통해 분리해야 함.

➡ "Reducer에서만 상태를 변경할 수 있다!"

➡ "Reducer는 같은 입력(Action + State)에 대해 항상 같은 출력을 내야 한다!"

---

3️⃣ 액션 기반 상태 변경 (Action-Driven State Management)

TCA에서는 Action을 통해 상태 변경이 이루어집니다.

이렇게 하면 상태 변경이 명확하게 추적 가능 해지고, 어떤 이벤트가 발생했는지를 쉽게 알 수 있습니다.

enum Action: Equatable {
    case increment
}

• 사용자의 입력을 Action으로 정의하고,
• Reducer에서 Action을 받아 State를 변경합니다.

➡ "모든 상태 변경은 명확한 Action을 통해 이루어진다!"

---

📝 정리: TCA가 Redux 패턴에서 영향을 받은 이유

✅ 핵심 개념	✅ 설명
단일 상태 (Single State)	앱의 모든 데이터를 하나의 State 구조체에서 관리
순수 함수 기반 상태 변경 (Pure Function Reducer)	상태 변경은 반드시 Reducer에서만 처리 (View에서 직접 변경 불가)
액션 기반 상태 변경 (Action-Driven State Management)	Action을 통해 명확하게 상태를 변경

---

🔍 TCA는 단방향(Unidirectional) 아키텍처이다.

TCA(The Composable Architecture)는 Redux 패턴에서 영향을 받아 단방향 데이터 흐름(Unidirectional Data Flow, UDF)을 따르는 구조이다.

즉, 데이터가 한 방향으로만 흐르며, 상태 변경이 예측 가능하게 관리된다.

---

1️⃣ 단방향 데이터 흐름이란?

단방향 데이터 흐름이란 사용자의 입력(액션)이 상태(State)를 변경하는 유일한 경로가 정해져 있는 구조 를 의미한다.

✅ 단방향 데이터 흐름 (TCA에서의 흐름)

1. 사용자가 버튼을 클릭하면(Action)
2. Reducer가 Action을 받아 State를 변경하고
3. View가 변경된 State를 다시 렌더링한다.

📌 단 하나의 방향만 존재한다: [사용자 입력] → [Action 발생] → [Reducer] → [State 변경] → [View 업데이트]

---

2️⃣ TCA의 데이터 흐름 (Unidirectional Flow)

TCA에서 데이터는 아래의 경로로만 이동한다.

(1) View → Store (Action 전송)

• 사용자의 입력(버튼 클릭 등)이 발생하면 Action을 Store.send(action)을 통해 전달한다.

struct CounterView: View {
    let store: StoreOf<CounterFeature>

    var body: some View {
        WithViewStore(store, observe: { $0 }) { viewStore in
            VStack {
                Text("\\(viewStore.count)")
                Button("+") {
                    viewStore.send(.increment)  // Action 발생
                }
            }
        }
    }
}

• 사용자가 버튼을 누르면 Action.increment가 Reducer로 전달됨.

---

(2) Store → Reducer (상태 변경)

• Reducer에서 Action을 받아 State를 변경한다.

struct CounterFeature: Reducer {
    struct State: Equatable {
        var count: Int = 0
    }
    
    enum Action: Equatable {
        case increment
    }
    
    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .increment:
                state.count += 1  // 상태 변경
                return .none
            }
        }
    }
}

• Reducer는 순수 함수(Pure Function)로, Action을 처리하고 새로운 State를 반환함.

---

(3) Store → View (상태 전달)

• Store가 변경된 State를 View에 전달하면, SwiftUI가 다시 렌더링한다.

WithViewStore(store, observe: { $0 }) { viewStore in
    Text("\\(viewStore.count)")
}

• WithViewStore를 통해 State를 구독하고 있다가 count 값이 변경되면 화면을 다시 그림.

---

3️⃣ 단방향 데이터 흐름의 장점

✅ 예측 가능함 → 상태(State)가 변경되는 유일한 경로가 존재하므로, 디버깅이 쉬움.

✅ 테스트가 용이함 → Reducer가 순수 함수이므로, 같은 입력(Action)이 들어오면 같은 결과(State)가 나와서 단위 테스트가 가능.

✅ 유지보수성이 높음 → 상태(State), 로직(Reducer), UI(View)가 분리되어 코드가 명확함.

---

4️⃣ 양방향 데이터 흐름과의 비교

✅ 양방향(Bidirectional) 데이터 흐름이란?

• 상태(State)를 여러 곳에서 직접 수정 하거나,
• 데이터가 상위 컴포넌트에서 하위 컴포넌트로 내려갈 수도 있고, 반대로 올라갈 수도 있는 구조.

💡 예시: SwiftUI의 @Binding을 사용한 양방향 데이터 흐름

struct ParentView: View {
    @State private var count = 0

    var body: some View {
        ChildView(count: $count)  // 양방향 바인딩
    }
}

struct ChildView: View {
    @Binding var count: Int  // 상태를 직접 수정 가능

    var body: some View {
        Button("+") { count += 1 }  // 상태를 직접 변경
    }
}

• @Binding을 사용하면 하위 뷰에서 상위 뷰의 상태를 직접 수정 가능.
• count += 1이 직접 실행되어 State가 변경됨.
• TCA와 달리, 상태 변경이 어디서든 발생할 수 있어서 예측하기 어려울 수 있음.

---

🧘 마치며…

다음 글에서는 간단한 예제와 함께 최신 버전의 TCA의 핵심 개념과 동작 과정을 알아보도록 하겠습니다.