Flux는 페이스북 웹 앱에서 사용되고 있는 GUI 아키텍처이다. 데이터의 흐름이 단일 방향인 것이 특징인 아키텍처이다. React의 Redux도 Flux를 활용한 패턴이라고 한다.
Action -> Dispatcher -> Store -> View
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의 구성요소의 데이터 흐름이다. 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 Creator의 역할
Action Creator와 함께하는 데이터 흐름
Dispatcher는 ActionCreator가 만들어준 Action을 받아서 Store에 전달해주는 역할을 한다.
하나의 App에는 하나의 Dispatcher만 존재 가능하다, App과 동일한 LifeCycle로 존재하거나 Singletone으로 존재하는 경우가 많다.
Dispatcher가 Action을 Store에 전달하는 방법
ActionCreator가 Dispatcher에게 Action을 보내기.
ActionCreator -> dispatch() -> Dispacther() -> callBack() -> Store
Store는 Dispatcher로 부터 Action을 받아서 Action의 type과 data로 자기자신을 업데이트한다. 업데이트된 Store는 최종적으로 뷰에 반영된다.
Store는 Dispatcher의 register 메소드로 Callback을 등록하고, Store는 Callback으로 부터 Action을 받는다. 새로운 Action으로 Store에 변화가 있을시 구독되어있는 뷰에 알려준다.
Store의 초기화, register 타이밍과 Dispatcher에서 Action을 보내는 타이밍에 주의해야한다. 타이밍이 맞지 않으면 Store가 받을 수 없다.
장점
단점
참조 : https://unnnyong.com/2020/06/16/ios-%eb%b2%88%ec%97%ad-flux/