Flux
Flux는 페이스북 웹 앱에서 사용되고 있는 GUI 아키텍처이다. 데이터의 흐름이 단일 방향인 것이 특징인 아키텍처이다. React의 Redux도 Flux를 활용한 패턴이라고 한다.
단일 방향 데이터 흐름
Action -> Dispatcher -> Store -> View
- Action : 실행되는 관리를 특정하기 위한 type과 실행되는 관리를 연결하는 data를 가지는 Object
- Dispatcher : Action을 받으면 자신이 등록된 Store에 전달.
- Store : state를 가지고 Dispatcher로부터 전해진 Action의 type과 data를 따라서 상태를 변경.
- View : Store의 State를 구독하고, Store의 State의 변화에 따라 화면을 업데이트.
Dispatcher에 Action을 주입시키는 것으로 데이터흐름이 시작되고, Dispatcher는 Action을 Store에 전달한다. Store는 받은 Action을 기반으로 자신의 상태를 업데이트하고 Store의 상태를 구독(Subscribe)하고 있던 View가 상태 변화에 따라 화면을 업데이트 한다.
단일 방향은 Flux 아키텍처에서 절대적이므로 View에서 Store를 직접 변경하는 것은 안된다.
따라서, View는 Dispatcher에게 Action을 넘기는 걸로 Store에 무언가를 알릴 수 있다.
유저에게 터치(무언가의 입력)을 받은 View는 입력을 Action으로 만들어서 Dispatcher에게 전하고, Dispatcher는 받은 Action을 Store에 전달한다. Store는 Action을 통해 상태가 변경되고, 그 Store를 구독하는 View의 화면이 업데이트 된다.
View의 구성과 데이터 흐름
아래 초록색 계열의 부분이 View의 구성요소의 데이터 흐름이다. IOS의 경우, View는 UIViewController, UIView(SwiftUI는 View)가 된다.
View -> UserIntraction ---> Store
View에서 데이터 흐름이 시작되는 User Interaction == 유저의 터치(입력), View가 상태를 가지면 안된다. 유저가 Action을 만들어서 Store로 전달해서 Store가 갖도록 해야함
Store -----> View
View로 향하는 데이터 흐름은 Store의 상태를 View가 반영하기 위한 데이터 흐름. Store의 상태는 RxSwift, KVO, NotificationCenter로(구독을 통해) 받게 된다.
Action의 구성과 데이터 흐름
Action Creator의 역할
- 무언가의 실행을 하고, 그 결과로부터 Action을 만든다.
- 만들어낸 Action을 Dispatcher로 보내기.
Action Creator와 함께하는 데이터 흐름
- View에서 발생한 UserInteraction의 처리를 ActionCreator에서 실행한다.
- ActionCreator는 Web API Util을 통해 Web API로 통신하고, 통신결과를 Action으로 만들고 Dispatcher 에게 전달한다.
Dispatcher의 구성과 데이터 흐름
Dispatcher는 ActionCreator가 만들어준 Action을 받아서 Store에 전달해주는 역할을 한다.
하나의 App에는 하나의 Dispatcher만 존재 가능하다, App과 동일한 LifeCycle로 존재하거나 Singletone으로 존재하는 경우가 많다.
Dispatcher가 Action을 Store에 전달하는 방법
- Dispatcher에 register(callback:) 함수가 존재.
- register 함수를 Store에 불러서 Callback을 등록하고 Action을 받는다.
ActionCreator가 Dispatcher에게 Action을 보내기.
- Dispatcher에 dispatch(_:) 함수가 존재.
- dispatch(_:) 함수를 ActionCreator가 사용.
ActionCreator -> dispatch() -> Dispacther() -> callBack() -> Store
Store의 구성과 데이터 흐름
Store는 Dispatcher로 부터 Action을 받아서 Action의 type과 data로 자기자신을 업데이트한다. 업데이트된 Store는 최종적으로 뷰에 반영된다.
Store는 Dispatcher의 register 메소드로 Callback을 등록하고, Store는 Callback으로 부터 Action을 받는다. 새로운 Action으로 Store에 변화가 있을시 구독되어있는 뷰에 알려준다.
Store의 초기화, register 타이밍과 Dispatcher에서 Action을 보내는 타이밍에 주의해야한다. 타이밍이 맞지 않으면 Store가 받을 수 없다.
iOS App 에서 Flux 구성과 데이터 흐름
장점
- 데이터 흐름이 단일 방향이기 때문에 흐름의 추측이 가능하다
- View, Action, Dispatcher, Store의 역할이 나뉘어져 있기 때문에 어디서 실행되어야 하는일인지 파악하기 쉽다.
- Dispatcher가 App의 중심(허브)이기 때문에 테스트 결과, 테스트 Mock 데이터 주입이 간단하다
- 앱이 거대해져도 확장성이 있다.
단점
- Action을 Dispatch할 때, Store가 아직 생성되지 않는 경우가 있으므로 Store의 LifeCycle을 신경 쓸 필요가 있다.
- 앱의 규모가 커질수록 Action도 거대해진다.
- Store를 변경하기 위해서는 Action을 생성해서 Dispatcher를 통과해야만 해서 번거로울 때가 있다.
참조 : https://unnnyong.com/2020/06/16/ios-%eb%b2%88%ec%97%ad-flux/
